Re: [Gimp-developer] GAP
On Sunday 05 August 2007 06:45, [EMAIL PROTECTED] wrote: > > Hi, > > > > On Sat, 2007-08-04 at 01:58 -0300, Joao S. O. Bueno Calligaris wrote: > >> I am getting an error linking gimp-gap svn in a 64bit > >> enviromment, in both trunk and gap-2-2 branch: > > > > That's a problem with the copy of libavcodec that is included > > with GAP. You better disable support for libavcodec when > > configuring gap. For GAP 2.4 we should include a recent version > > of libavcodec. > > > > Sven > > To expand on Sven's answer a little, the FFMPEG project does not > provide a stable API; therefore the GAP includes the source for a > specific snapshot of the code and staticly links to it. The > snapshot in the GAP's tree is from 2005 ; it needs to be updated > and the GAP code modified to employ the new FFMPEG API (also for > 64-bit support and GCC4 compatibility as well). > > Wolgang Hofer, the main developer of the GAP, is working on that > update but he does not have direct access to the Internet right > now. It may be a few months before updated FFMPEG support is > available but it is being worked on. In the interim, I would > suggest disabling libavcodec support and using an external utility > to convert your frames to video. > Hehh..that is a bit too much, ain't it? It actually _did_ build when I tweaked the Makefiles in the library dirs (and only there) to include the "-fPIC" GCC directive. 64 bit, GCC 4.1.1 It is not like "this will only work in 2010 or 2012". js -><- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GAP
On Friday 03 August 2007 17:18, Sven Neumann wrote: > Hi, > > On Fri, 2007-08-03 at 23:54 +0400, Alexandre Prokoudine wrote: > > > Are you absolutely sure that you removed the "fuzzy" marker > > > after updating the translation? > > > > Yes, I am. > > OK, please try again after updating from SVN. I added some missing > calls to gimp_plugin_domain_register(). That should fix it, but > there might be more places affected that need a similar fix. > > > Sven I am getting an error linking gimp-gap svn in a 64bit enviromment, in both trunk and gap-2-2 branch: /usr/bin/ld: bitstream.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC bitstream.o: could not read symbols: Bad value collect2: ld returned 1 exit status make[4]: *** [libavcodec.so] Error 1 when doing: gcc -shared -o libavcodec.so bitstream.o utils.o mem.o allcodecs.o mpegvideo.o jrevdct.o jfdctfst.o jfdctint.o mpegaudio.o ac3enc.o mjpeg.o resample.o resample2.o dsputil.o motion_est.o imgconvert.o imgresample.o mpeg12.o mpegaudiodec.o pcm.o simple_idct.o ratecontrol.o adpcm.o eval.o dv.o error_resilience.o fft.o mdct.o mace.o huffyuv.o cyuv.o raw.o h264.o golomb.o vp3.o asv1.o 4xm.o cabac.o ffv1.o ra144.o ra288.o vcr1.o cljr.o roqvideo.o dpcm.o interplayvideo.o xan.o rpza.o cinepak.o msrle.o msvideo1.o vqavideo.o idcinvideo.o adx.o rational.o faandct.o 8bps.o smc.o parser.o flicvideo.o truemotion1.o vmdav.o lcl.o qtrle.o g726.o flac.o vp3dsp.o integer.o snow.o tscc.o sonic.o ulti.o h264idct.o qdrw.o xl.o rangecoder.o png.o pnm.o qpeg.o vc9.o h263.o h261.o msmpeg4.o h263dec.o svq1.o rv10.o wmadec.o indeo3.o shorten.o loco.o alac.o wnv1.o ws-snd1.o aasc.o a52dec.o liba52/bit_allocate.o liba52/bitstream.o liba52/downmix.o liba52/imdct.o liba52/parse.o liba52/crc.o liba52/resample.o -lm -lz -ldl -Wl,--warn-common -rdynamic (trying the suggested "fPIC" makes build halt early on.) > > > ___ > 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] [Gegl-developer] PyGEGL instant crash
On Thursday 19 July 2007 19:28, Kevin Cozens wrote: > David Gowers wrote: > > Using Python 2.6, typing 'import gegl' at the interpreter prompt > > causes the following crash to immediately happen: > > [snip] > > > I'm also pretty sure that the bug lies in the pygegl module, as > > I've compiled and used many other modules for Python 2.6, with no > > problems, and I ran the babl and gegl tests successfully (and the > > gegl editor works okay too) > > I have only tested pyGEGL with the 2.4 version of Python. It > possible (or very likely?) that something has changed in the 2.6 > version of Python. I don't have the 2.6 version installed at the > moment so I can't investigate this further. Python 2.6??? The stable python is 2.5.1 - there is not even mention of a 2.6 release on teh python.org pages. David: do you mean python 2.5 instead? regards, js -><- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Fwd: LGM 2007 Final Report - Help needed
-- Forwarded Message -- Subject: LGM 2007 Final Report - Help needed Date: Thursday 10 May 2007 12:10 From: "Louis Desjardins" <[EMAIL PROTECTED]> To: "Sven Neumann" <[EMAIL PROTECTED]>, "Joao S. O. Bueno Calligaris" <[EMAIL PROTECTED]>, Plinnell <[EMAIL PROTECTED]>, "Cyrille Berger" <[EMAIL PROTECTED]>, "Boudewijn Rempt" <[EMAIL PROTECTED]>, "Igor Novikov" <[EMAIL PROTECTED]>, "Alexandre Prokoudine" <[EMAIL PROTECTED]>, "Jon Phillips" <[EMAIL PROTECTED]>, "Andy Fitzsimon" <[EMAIL PROTECTED]>, "Martin Poirier" <[EMAIL PROTECTED]> Hi guys, (I am writing to a few of the team leaders and please feel free to relay this request to the person in your team you feel would do the best job to gather the resquested information. Also, if you think I have forgotten somebody or a project, please let me know. — Thanks!) LGM 2007 has been a tremendous experience! I hope all travellers had a good trip back home! Thank you so much for being in Montréal with us! Thank you so much for all your encouragements and enthusiasm! We now must think about the final report of this year's LGM. This is important to keep track of what was accomplished and to prepare next year's edition. It is of upmost importance for our sponsors, to secure next year sponsorship, to let them know how and why LGM is important for the participating projects. From each team I would ask a short but enough detailed summary of what was accomplished since last year. It can be both quantitative and qualitative. I doesn't need to be a long text. Since it is the first time we do that (I think) I leave it up to you. We will make it a nice layout and will include some nice pics as well. The report will help us draw attention on LGM and will also serve as a reference point for the teams. Thank you for responding quickly. We'd like to have the report done within a few weeks from now. Cheers! Louis -- Louis Desjardins Organisateur / Organiser Libre Graphics Meeting 2007 - Montréal www.libregraphicsmeeting.org/fr www.libregraphicsmeeting.org +1 514 934 1353 HAE / EDT GMT -4 --- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Pixel coordinates input type for script-fu?
On Tuesday 01 May 2007 17:05, Mark Lowry wrote: > --- "Joao S. O. Bueno Calligaris" <[EMAIL PROTECTED]> > > wrote: > > Hi - no, there is no official way to do that. > > > > What I do in my scripts is require the user to start > > a Path with the > > bezier tool before calling the script - The script > > then use the > > coordiantes of the first (or how many I want) points > > of this path as > > input coordinates. These can e read through the PDB. > > > > js > > -><- > > I have thought about doing that and I think that is > the way I will have to go. I'm confused with how to > extract elements from the vector returned by > gimp-path-get-points. I thought I understood that > (vector-ref vector k) was the way to pull the k-1 > element from the vector, but when I input (vector-ref > '#(1 1 2 3 5 8 13 21) 5) I just get an errobj on > vector-ref. What do I need to do to be able to > extract a value from the result of > (gimp-path-get-points image path)? oh man.,.. 2 things: 1) I do python-fu, not Scheme (script-fu) - so I have erased from my mind the esoteric ways of getting elements out of a vector or array in Scheme. btw, if your plug-in is of any complexity, unless you think your time is being well spent as you exercise your mind around how to get and use data with scheme expressions as an extra exercise, I'd suggest writting it in python. If you are on windows, that will only work witht he developemtn version of GIJMP, though. But it has the advantadge of letting you worry with your problem instead of the language _and_ your problem. 2) this very API is being obsoleted in GIMP 2.3.x - there are all new vector manipulation calls in place, that can finally deal correctly with multiple stroke vectors (not needed to fecth just one or two coordinates anyway) In python, an interactiuve session exploring the return values might just display: >>> img = gimp.image_list()[0] >>> pdb.gimp_path_get_points (img, "a") (1, 0, 15, (103.03428571428572, 101.01142857142861, 1.0, 104.74857142857149, 98.902857142857101, 2.0, 529.68571428571431, 102.38, 2.0, 529.480002, 102.039996, 1.0, 529.27428571428572, 101.679995, 2.0)) >>> v = pdb.gimp_path_get_points (img, "a") >>> points = v[3] >>> points (103.03428571428572, 101.01142857142861, 1.0, 104.74857142857149, 98.902857142857101, 2.0, 529.68571428571431, 102.38, 2.0, 529.480002, 102.039996, 1.0, 529.27428571428572, 101.679995, 2.0) >>> points[0], points[1] (103.03428571428572, 101.01142857142861) (the ">>>" are the prompt, not part of the language) -- Bill...could you see if it iyou can add a simple api for retrieving the sample points? I think this will bother no one at this point, it is starightforward as you said, and...we want to get 2.4 out, so it has to be done real soon. js -><- > > > __ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Pixel coordinates input type for script-fu?
On Tuesday 01 May 2007 00:15, Mark Lowry wrote: > I'm working on a script in which it would be > advantageous to use the mouse to click on an image and > have the pixel coordinates captured as an input. > Right now I have to manually enter the coordinates for > four points, which is a tedious process. > > Is there a way to capture these coordinates as inputs > to a script? If not, where is the appropriate place > to suggest a feature request for this? > Hi - no, there is no official way to do that. What I do in my scripts is require the user to start a Path with the bezier tool before calling the script - The script then use the coordiantes of the first (or how many I want) points of this path as input coordinates. These can e read through the PDB. js -><- > Thanks . Mark > > __ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > ___ > 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] How to change the active current tool from a plugin?
On Wednesday 25 April 2007 17:27, Laurent gauvrit wrote: > hello everybody, > > I work on a hopefull edge detection plugin for gimp and i need to > change the active current tool by a button in my plugin. > > Anyone know the answer??? Yes. The answer is: it is not possible at the moment. Sorry for that. A plug-in can itself use the tools, , but it can't change most things in the UI context. js -><- > > > > thanks > > > lolo > > _ > Windows Live Spaces : créez votre blog à votre image ! > http://www.windowslive.fr/spaces > > ___ > 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] how to call gimp procedure from text terminal ?
On Monday 23 April 2007 21:02, stu seven wrote: > +I asked this on the google group, but with no answer yet... > > How can a menu item or gimp procedure be called from a > text terminal, with a graphical gimp session already running ? > > I know that, using a function name, and parameters, this can > be done in batch mode, for instance... however, all Im looking for > is to "remotely" open the function dialog, via the text terminal. > > Is this possible... or... some other way of opening the menu > item dialog besides clicking on it ? > Such a terminal would have to be done from within GIMP. The easiest way I can think of doingthis is writing a python plug-in that will listen to a socket and execute what you type in there once you connect to that socket. > thanks > ___ > 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] Fwd: [CREATE] Standard RAW File Format (fwd)
-- Forwarded Message -- Subject: [CREATE] Standard RAW File Format (fwd) Date: Tuesday 17 April 2007 05:36 From: Kai-Uwe Behrmann <[EMAIL PROTECTED]> To: libtiff - Liste <[EMAIL PROTECTED]>, Kunst Tuepfel <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Hello, just to inform all the digital camera RAW developers out here. Sorry for any duplication. -- Forwarded message -- Date: Fri, 16 Mar 2007 18:18:33 +0100 From: Dietmar Wueller <[EMAIL PROTECTED]> To: Dietmar Wueller <[EMAIL PROTECTED]> Subject: Standard RAW File Format -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, as a member of the ISO TC42 (technical committee for photography) working group 18 (electronic imaging) standards group I would like to inform you that the existing Tiff/EP (ISO 12234) standard for images captured by digital cameras is currently under revision. The Adobe DNG format was derived from this standard and the group has Adobe's permission to incorporate modifications and developments made for DNG in the new standard. In addition the standards group is asking all interested people for comments and requirements - which are not part of the current DNG or Tiff/EP standard - to be incorporated in the new standard. If you have such please forward them to me by the end of April. Hopefully we will soon be able to provide a standardized file format which meets everybody's expectations and gets a wide support by camera manufacturers, software vendors, and photographers. Please forward this message to everybody who may have contributions to the revision. Best regards Dietmar Wueller Image Engineering Dietmar Wueller Augustinusstr. 9d 50226 Frechen Germany phone +49 2234 912141 fax +49 2234 912142 [EMAIL PROTECTED] www.image-engineering.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF+tFp7Olj94xfLY4RArPaAKCtTyhP4rWNjRwfNmb5WW7B9TrtngCfYKMm qSARyPFRA4/lBFuQE54LTm0= =1Yi9 -END PGP SIGNATURE- ___ CREATE mailing list [EMAIL PROTECTED] http://lists.freedesktop.org/mailman/listinfo/create --- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] internal representation of a selection
On Friday 30 March 2007 13:10, Helmut Jarausch wrote: > Hi, > > can somebody, please, point me to some information on how a > selection is represented (internally) within Gimp and how one can > access this. Is it represented by a matrix of bits? > If the selection has many holes it's not sufficient to have a lower > and upper bound for each pixel row. I need the selection exactly > for my attempt at a new healing tool. > > Many thanks for a pointer, > Hi Helmut - the selection is a matrix of bits, yes - a "drawable" object, with one byte per pixel, meaning the "strenght" of the selection at that point. the call gimp_image_get_selectin available for plug-ins can return you the selection as a drawable object. Through the UI you can simply enable the quickmask (click on the little square to the left of the hor. scroll bar on an image window), to transfer the selection to an editable image channel. js -><- > Helmut Jarausch. > > ___ > 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] [Gimp-Developer] One-click bi nary downloads via the gimp website
On Thursday 29 March 2007 07:22, Robert L Krawitz wrote: > We already direct users to recomendeded binaries, and as long as > we continue to be clear that we don't build those binaries > ourselves, why should we not make it easier to reach those? > > Because whatever disclaimers etc. you use, users will see the > binaries as coming from the GIMP project, and will blame you if > there are any download problems or corrupted (or trojaned!) > binaries. Just then - who will they blame if a binary from gimp-win crashes? The names and e-mails for complaint may be the ones in the gimp-win page, but on the users mind, the program that failed is the GIMP. Back on the thread topic - when lecturing about the GIMP, the instructions I give for windows downloading are something like "google for Gimp Windows Download". Having a download link straight from GIMP .or gmaybe could be a nice thing, but it is not the most important. There is the issue of needing to download the GTK+ installer as well - and the instructions ofr that - so it is not only linking to the GIMPwin installer from gimp.org/downloads. However - (I am reviewing now), a user trying to download the GIMP for windows now, starting from gimp.org has to go through: www.gimp.org www.gimp.org/downloads www.gimp.org/windows gimp-win.sourceforge.net/ gimp-win.sourceforge.net/stable.html And then grab the gtk+, and gimp win binaries. And all those pages are in English only - (most people in my target audiences are not proeficient enough in English - so, just imagine all those pages are in some language you don't understand, and you will see it is rather unprobable that one would click on the correct links at each of then) Regardless of providing a direct link to the binaries, I think that a direct link from gimp.org/downloads to a page with the same instructions and links that live currently live in gimp-win.sourceforge.net/stable.html is a must. Discussing the i18n of some or all of these pages would be OT here, but that is of concern to me as well. js -><- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Rudeness on gimp devel and bugzilla - was: Re: Tools
On Monday 19 March 2007 08:11, Simon Budig wrote: > > IMHO, refraining from posts like this could greatly improve the > > atmosphere of this list. > > It is really up to you to help somebody with answering his > > question or not to help, but this "answer" only hurts and helps > > nothing. > > I don't agree with you there. >... (remaining ranst tossed on bascket) Simon, where does that forbid one to add words like "thanks", "please", "would" and etc... to even a short answer, like a FAQ URL??? You see, the GIMP is not exactly with exceeding developer resources, and every single person I see trying to approach the project either here or over bugzilla gets a rude answer that might have turned then away for good. Examples from the last 48 hours include a "help yourself" (bug #329020 - 2007-03-20), "we don't take bug reports against outdated development versions anyway." (bug #420170, 2007-03-19) The guys organizing LGM had called my attention to the point that GIMP is a project perved as hostile towards newcomers. I even addressed in private some hostile postings on this list over the last weeks to try to start changing this general behavior - but it looks it is just too overspread. It is not really hard - and that is to you Mitch, you Sven, you Nomis, to simply rememebr the person on the other sidee is sitll a human being, is not it? Not less human for having less abilities to compile/hack complicated software projects, much less for simply not knowing how to do so. You can think ut whatver you want, mutter whatver you want, write a scratch however you want - I ma just askign that before hitting the "post" button you go back to thetext and add some of the magic words - even if in your heart you are lying. Example: from: "we don't take bug reports against outdated development versions anyway." to: "Please, post bugs only using the latest development version. " (that if one is really unwillingly to type a few more characters) sincerely, js -><- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Brush Scaling
On Thursday 15 March 2007 07:22, jbaker wrote: > Thanks for all the work on this one, it works great... > > I was just curious if there are any plans add the ability to scale > and rotate the standard brushes with python ? I did a quick search > in the procedure browser but didn't see anything except the > functions for the generated brushes... > > thanks, > no plans made - except for generated brushes (the ones you can create and edit from within the brush dialog). But this is an area I am thinking about. (actually, mostly the pdb for brush stroking) Please say a little more on what you are planning to do (the final effect). Regards, js -><- > jerry > ___ > 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] memory manage in python-fu
On Sunday 11 March 2007 20:54, D. Stimits wrote: > I have not found any python-fu way to "close" a file, or to reclaim > memory after creating an image or layer. Is there such a thing? Is > there instead some sort of garbage collection? > > Speculating about why it claimed it was out of memory, I'm > wondering if the hard drive simply was too slow responding. It's a > laptop, running with core duo, entirely in ram. The drive is thus > much slower than the ability to consume ram. How does gimp > determine that there is no space left on the device...is it a > timeout in addition to other means? The normal python way would be to set the object for destruction after it is no longer used. However, it may well be possible that the GIMP bindings to python are not deleting GIMP images creted from within python, as it should be done. I had, myself, never thought of using a script o create so many images. As you rerro r mesage is "no space left on device" - please try to cehck gimp preferences for tmp dirs, maybe it is using another partition that might be getting filled. The increaseof RAM usage for itself however shows there is something wrong going on - could you please fill a bug report about this at bugzilla.gnome.org ? If possible, please attach a minimalistic version of your script taht would trigger the problem. Thank you, js -><- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] SoC project ideas
On Tuesday 06 March 2007 05:03, Sven Neumann wrote: > Hi, > > I have read through the list at > http://wiki.gimp.org/gimp/SummerOfCode and I think we need to > triage the list and try to come up with fewer but more detailed > proposals. Here are some comments to get us started: > I added some more ideas to the list on the wiki I think could be feasible as GSoC projects: * Enhancing Painting with parameter curves Currently there are quite a few options to use with the paint tools, however, mapping how these options could vary with pressure, tilt, speed, angle of painting is somewhat limited. A complete tabbed dock, where new curves could be added that would map one input variable to paint option could increase several fold the options available to artists. A request for this is drafted in [http://bugzilla.gnome.org/show_bug.cgi?id=119240|bug #119240]. * Categories for brushes, fonts, gradients and palettes If one adds too many fonts or brushes to GIMP, they quickly become un-manageable through the existing UI. Implementing a way of organizing these resources in sub-categories, in a way that one resource could be present in more than one category (like thrugh the use of tags) in a nice UI could overcome these limitations; * Font Selector Widget We need something better. Something that is reusable. Something to turn choosing fonts into a pleasure, rather than a pain. Something to leave the competition on the dust. And I also came up with this idea, but did not add it to the wiki, because it certainl should have further consideration from the developers, more than the others, to get toeven a rughidea of what will be needed: * Layer Folders UI With the upcoming integration of GEGL, there finally will be internal support for layer grouping, even more than one level of it. Aide form the work on the core, we will need a good UI to be the evolution of the current layers dialog. If the GIMP will only allow nested layers, then this should be mroe or less trivial. If GIMP will allow full usage of GEGL, and allow the same layer to be used as source for multiple operations then we will need a brilliant UI. js -><- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] SoC project ideas
On Thu, 2007-03-08 at 01:43 -0500, Kevin Cozens wrote: > > It is pretty easy to crash many (most?) of the plug-ins when > > passed bad data from some script. Checks in libgimp can stop GIMP > > from crashing but will only go so far to stop the plug-in from > > crashing. I think it would be a worthwhile project to get done at > > some point. In terms of SoC, it would be a low priority project. > > > > This also raises the question as to whether the plug-in-template > > can handle being passed bad data or not. If not, it should be > > updated to show new plug-in authors how to properly write a > > plug-in to deal with the possibility of receiving bad data. > On Thursday 08 March 2007 04:12, Sven Neumann wrote: > The question is, is this a serious problem at all? If a script is > broken and the result is a plug-in that crashes, is that really a > problem? A crashing plug-in shouldn't cause further harm and > there's a warning that informs the script author that there's a > problem. The script can then be fixed. I fully agree with Sven here. Besides, I can't imagine how this could be something cool, which, IMHO, GSoC stuff should be. js -><- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Libre Graphics Meeting - last call
Ok, that is it. We are closign the list of people who will need sponsorwsship to attend LGM 2 in Canada this year. Whoever wants to go an d apply for air tickect refund, please do contact me in the next hours. I will also ask for people who think they are on the refunding list, but have had no word from me yet, to write me - ASAP. We better have some few extra e-mails flaoting around than missing someone. js -><- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] gimpwin install
Hi, I, exceptionally, have a question reguarding the GIMP builds for windows: How hard would it be to create a .msi installer for gimp + gtk+, instead of the current zip files? It seems to be quite standard nowadays, and a couple high profile free software packages are uisng it. I think that could be a nice surprise for win users. regards, js -><- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] LGM - goint to, and GIMP presentation
GIMP presentation at LGM - Hi people - LGM guys are asking for a GIMP presentation at the Libre Graphics Meeting. Something to show off GIMP's capabilities, new features in the 2.4 version, and plans for the future. The other big projects there will feature such a presentation (more or less like Andyfitsz's presentation last year, sans the bugs) """ usage is of utmost importance; we expect many graphics pros who haven't even heard of FLOSS""" So, if anyone wants to present such a lecture, please step ahead - Just remembering you that Pippin will already present something about the achievements and other dark magic in GEGL. --- In time: anyone who wants to get GIMP/LGM sponsorship to be there, should contact me ASAP, if had not done so (ok, some people did not write me, I picked the names inthe GIMP wiki as well - but if in doubt contact me). People already confirmed should start looking after booking their flights. Again, if in doubt, just ask me. http://www.libregraphicsmeeting.org js -><- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Layer Groups
On Tuesday 20 February 2007 09:54, jEsuSdA wrote: > Hello! > > I'm not a developer, but i suscribed to the devel list because i > work everyday with gimp and i like to know how it grow day by day. > > First at all i would to congratulate us for you efforts. > I love Gimp and i try to install it wherever i can (friends, > family, office, ...) and i have made some conferences to stimulate > gimp use. > > My question is why and when Gimp will include LAYER GROUPS or > FOLDERS (more useful)? > > I think Layer Folders were a great utility, and when i work with > lot of layers i need them. ;) > Hi Jesusda (I should regard that my typing skills are bad enough already without me trying to copy the casing in your nick) As soona s gimp 2.4 is out, we will start working in merging teh Gimp core with GEGL. GEGL provides teh equivaletn of layer folders out of the box - so it is almost certain that teh gimpv ersion following the next one, be it 2.6 or 3.0, will feature those. However, we are at the moment with very little main force to propel the GIMP forward - given the natrue of your work maybe you cuod yurself, or incetivate some of your students, t join our efforts. That said, I have made a hak soemwher that uses Python plug-ins and parasites to be able to name certain layer groups and have some minimal funcitonality with that. I can mail you those f you are interested. Regards, js -><- - http://www.libregraphicsmeeting.org/ > Thanks! > > jEsuSdA 8) > > Pdta: Excuse my poor english, i'm from spain. ;) > > > ___ > 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] strange localization behaviour (gimp-2.3-svn)
On Wednesday 07 February 2007 07:31, Alexandre Prokoudine wrote: > On 2/6/07, Sven Neumann <[EMAIL PROTECTED]> wrote: > > Hi, > > > > On Mon, 2007-02-05 at 22:38 +0100, Marco Ciampa wrote: > > > I just noted this strange behaviour: when I see the the > > > Image menu->View->Display filters->Color Deficient Vision > > > options (Protanopia, Deuteranopia, Tritanopia) with the Italian > > > locale, _all_ but these three options are translated. Is it my > > > svn copy fault or does it have this behaviour in other > > > languages too? > > > > Sorry, but I don't understand your question. What's translated > > and what's not? And did you already check in the it.po files that > > the strings have been translated at all? > > As of current po-libgimp/it.po > > #: ../modules/cdisplay_colorblind.c:67 > msgid "Protanopia (insensitivity to red)" > msgstr "Protanopia (insensibilità al rosso)" So, do you know if ther eis an Italian word for it,a nd which it is? If there are proper Italian words for that, just send then to the list and we will fix(exceptionally, the normal course would be to ask for the change in bugzilla.gimp.org) I am the trasnaltor for Brazillian portuguese, and as far as I know these exact terms can be used in my language, so they are not changed in the pt_BR translation as well. js -><- > > Alexandre > ___ > 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] LGM brochure
On Monday 05 February 2007 19:20, cedric GEMY wrote: > To make the LGM brochure that has to be distributed in canadian > magazins, i'm looking for the best works made with Gimp. If anyone > have some link or files, please send. We'll choose from those one. > I will have to ask you to look at the work of some people from here. They've been making an electronic fanzine over hte last year, and there is some quite astonishing stuff inside. Ms to f it 100% GIMP. Unfortunatelly, all the articles are in Portuguese only. http://www.ogimp.com.br/modules/tinycontent/index.php?id=1 (The artwork is inside the PDFs - if you need to contact the authors for licensing/original art, please CC me - some of then are quite bad at even reading English) > cedric > ___ > 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] LGM/2007
LGM 2007 is approaching, and we have to deal which GOIMP people will be attending. There will be limited funding to sponsor the air fare costs, comming from GIMP donations, and possibly a little from LGM funding. In order to knwo which people can be sponsred, we need first to know who wants sponsorship (and to a certain degree, how hard one wnats to go/needs the sponsorship to go/is involved with the project). People who is attending can add their names at http://wiki.gimp.org/gimp/TellUsYoureComing . Anyone who will need the sponsorship or simply wnat to query about the possibility, should e-mail me as soons apossible, so it can be deliberated among the GIMP developers. Regards, js -><- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enabling plugins to get the user to click a point on the image.
On Thursday 18 January 2007 04:58, David Gowers wrote: > Manuel pointed out, The gimp currently lacks any way for a plugin > to get a coordinate from the image (eg. click on the 'seed' pixel). > I've often wanted to do this, and it is a bit awkward without it. > Has implementing this been avoided, or is it just an oversight? > > Some example usages: > * Color mixer: click on any number of pixels then press ENTER to > set FGcolor to a mix of all those colors. > * Zone selector: click on a zone to select it > * Word balloon creation (see a recent post on gimp-user) -- click > a series of 5 points to draw a word balloon (size, point shape and > location) Hi David: If you do not need it in real time, that is, if picking a point and only then caling a plug-in suits your needs, one can use paths. I have a couple of python-fu scripts myself that pick coordinates from the first, or first two nodes on the active path, and it is quite usefull. js -><- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Drawing zones
Ok - I've read the request and got the idea. I have the followwing proposal: what if one had a set of pre-loaded selections, and could switch back and forth among then with a single keystroke - Do you (and others) think it could be as usefull/more usefull/just the same as these proposed drawing zones? Why do I ask this? Because implementing what you are asking requires some fiddling in the core, and will complicate the interface with another kind of object, besides selections, channels, layers, masks, guides, sample points and the grid... Ok, you can imagine that what it brings of convenience for some it brings of complication to certain user groups. The idea I propose, instead, would use already existing objects, like this: one would store his drawing zones as a set of selections, each in a separate image channel, and a simple script, with no imput parameters, would replace the current selection with a selection in the channel stack. Todo this manually, one would have to: 1) select the channel tab in the layers/channels dock 2) select the apropriate channel 3) click on "channel to selection" 4) change back to the layers tab on the dock 5) select the actyual layer where one is drawing back 6) start painting. Looking at this, it si a lot of work, and the drawing zones seems a better idea. However, a script fu can perform steps 1-5 with a single keystroke (if one will select the next/same/previous channel on the stack that has been previusly used). so it becomes: 1) hit key that changes teh selection until the desired selection is set 2) start painting Which seems as practical as the drawing zones proposal. There is a final advantage in this proposal: it is ready for serving _now_,a s writing such a script would take less than 30min. What do you say? js -><- On Tuesday 16 January 2007 20:54, David Gowers wrote: > On 1/17/07, Thorsten Wilms <[EMAIL PROTECTED]> wrote: > > Hi! > > > > So I was asked to suggest new features on the mailing-list and > > only file bug report after they have been discussed there ... and > > it seems theres a misunderstanding to be resolved and i wouldn't > > mind more exposure for this ... :) > > > > > > My proposal is about an alternative to using either layers > > or saved selections to draw on areas of an image with sharp > > edges between them. > > > > http://bugzilla.gnome.org/attachment.cgi?id=80388 > > > > Shows a typical case, ignoring the background we have > > two such areas: body and hand. > > > > Drawing zones are about dividing the image into 2 or more > > (non-overlapping) regions. These zones would be a bit like > > multiple selections. If you start drawing in one zone, you can't > > draw over another zone without releasing the mouse-button / > > lifting the pen (same effect as drawing outside of the current > > selection). > > > > Such a feature would remove the need for using layers and moving > > between them > > or constantly changing selections in cases where adjacent areas > > need sharp edges between them. > > > > Using layers would mean constant switching between them. Same for > > selections. Long mouse-ways in both cases. Zones, once setup > > could be left active for long durations. > > > > This has nothing to do with split-views, Sven, as the image is > > shown the same way, not in parts. You would just need marching > > ants or similar for the zone extents and the ability to hide > > them. > > > > If it's still unclear, I'll provide graphical explanation. > > > > > > http://bugzilla.gnome.org/show_bug.cgi?id=397237 > > This would be wonderfully useful to me for CGing. You would need to > be able to define zones per-layer - It would only greatly reduce > the need for layers, not obviate them completely, for example when > I'm making an alternate coloration or remake of something, I like > to paste it over the original as a new layer, and use the enter key > to toggle it's visibility. > > I think you would have to use saved selections rather than layers, > to avoid the strange 'sibling-effects-sibling' behaviour (ie one > layer is real, other is zonemasks, but they're both in the same > list). If you specified a rule such as 'zonemasks are always the > layer immediately above the layer they apply to, if the layer has > zonemasks at all' you could probably manage layer based zonemasks > (of course they're better cause they can be in color.) ___ 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
On Tuesday 16 January 2007 06:49, Sven Neumann wrote: > Any volunteer for coordinating the GIMP participation to the > conference? If no one of the more active developers wants to do that, I might pick it. js -><- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp 2.4 workflow break
On Friday 12 January 2007 14:26, Bart wrote: > Hi, > > I often recognize a little workflow break when working with Gimp. > This happens when you click from the image window to tool window > (like layers) and do some thing there and then try out a specific > shortcut that works only on the image window. > This image window shortcut didn't work when a tool window is > focused, so you must first click back on the image window to > focused that and then you can use the specific short cut for the > image window. That isn't great at all i think. > > So what about if GIMP could recognized what was the last used image > window and if you press a specific shortcut that woks only on the > image window GIMP will call the command on the last used image > window? > > Thanx so far doing GIMP! 2.4 is getting great! > > > Karamba! > Bart. Hi Bart, I feel that too...when I am in computers other than my own. At home, I set up the GUI as I feel i tshould be: focus follow mouse. That means that I have only to hover a window for it to get in focus - no need to click. I've heard that even windows can be set up to behave like thta. Give it a try. js -><- > ___ > 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] The GIMP
On Thursday 07 December 2006 07:54 am, Michael Natterer wrote:
> On Wed, 2006-12-06 at 22:06 +0100, Sven Neumann wrote:
> > Hi,
> >
> > I'd like to do the following change to the comment at the top of
> > all source files in the GIMP tree:
> >
> > -/* The GIMP -- an image manipulation program
> > +/* GNU Image Manipulation Program
>
> I agree that old line sounds stupid ("an"), but why remove "GIMP"
> entirely?
>
> What about:
>
> /* GIMP - The GNU Image Manipulation Program */
I'd also prefer this way!
>
>
> ciao,
> --mitch
>
> ___
> 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] Rich Text editing (sort of)
Hi, The demand for a way of combining various text colors and fonts, along with other features in gimp text is high - even I myself need these features a lot. So, several months ago I started a plug-in to work around the text tool and provide some of these features, like the Dynamic Text did in the old times. I came back to it today, poured in some hacking time, and came up with a first usefull, if little, version. It can: create a "text" layer with varying font-family, sizes and colors. All left aligned. Edit back such a layer. The major drawback right now is that one has to select a portion of the text after it was typed in, and then select the font (family and size) and color to apply to that text. There are quite a few other bugs - but I find it rather usefull already. People interested, please, give a try: http://pion.sytes.net:4080/pyrichtext.py ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp python
On Monday 14 August 2006 04:17 pm, Sven Neumann wrote: > Hi, > > I have opened a bug report on what I believe to be the remaining > issues with gimp-python: > > http://bugzilla.gnome.org/show_bug.cgi?id=351287 > > Even though I said earlier that's it's perhaps too late for adding > i18n support, I feel now that we absolutely need to do this if we > want to install any Python plug-ins by default. > > But still, if i18n support is added, the usefulness of the plug-ins > should be reviewed and only the plug-ins that are considered useful > should be installed and have their strings marked for translation > (and reviewed). > > > Sven > > Hi Sven - thank you for getting to this. I am rather busy these days, but I will dig into it as soon as I have some time to the GIMP. I that is too late to 2.4 - well, thats is life. And in fact, even very simple scripts can be more usefull than the ones that ship by default, and at once be so simple taht could encourage more people to give a try at editing then. (center layer, apply a filter varying its parameters in a sequence o vertical slices of an image, and so on). Lets see what we all can come up with. JS -><- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] panning
On Thursday 06 July 2006 04:48 pm, Sven Neumann wrote: > Hi, > > On Thu, 2006-07-06 at 11:27 -0700, John Waugh wrote: > > I got no real response to the below question on gimp-user, so I > > guess it's time to start editing the source (: > > > > I would like to either > > 1) add a new 'pan' tool, to which I could then assign a key > > -or- > > 2) somehow remap the middle mouse button to a key. Or more > > accurately, have a key perform the same function as the middle > > mouse button, but hopefully not *lose* the middle-mouse > > functionality. > > > > Any opinions on which would be harder, or pointers how to > > accomplish either ? > > I would suggest that we finally implement it the way that has been > suggested here multiple times. Let's get rid of the Push-Move-Tool > feature that is currently bound to the Space key and use the Space > key for panning. > > Why not create a pan tool that could be pushed with any other key? Why not just make it configurable, instead of getting rid of the current functionality? I am a heavy user of the push->move feature, and I know of other people who are. There are 105 keys on the keyboard - and both features are a good thing to have with push functionality. I do not care if the move push is changed to any other key, and space be left to pan. But I care about loosing the current feature. > Sven JS -><- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] menu cluttage
On Wednesday 05 July 2006 09:36 pm, Joao S. O. Bueno Calligaris wrote: > On Wednesday 05 July 2006 04:47 pm, Sven Neumann wrote: > > Hi, > > > > On Tue, 2006-07-04 at 01:11 -0400, Kevin Cozens wrote: > > > Now that GIMP handles registration of the same menu item from > > > different plug-ins, I am just waiting for the time a user > > > reports a bug in Whirl and Pinch (for example) and doesn't > > > realize which version they were using (as in the Python version > > > or the C version). > > > > The Python version will of course not be in any stable release. > > > > And so far I don't see anyone complaining about my proposal to > > not install any Python scripts at all with GIMP 2.4. > > Hey. > It is allright for me if you do not install then- but I had > complained. - At least count that. Forgot to say this: not only had I complained, but I also offered to fix the issues with the python scripts right away, and you just said it was too late. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] menu cluttage
On Wednesday 05 July 2006 04:47 pm, Sven Neumann wrote: > Hi, > > On Tue, 2006-07-04 at 01:11 -0400, Kevin Cozens wrote: > > Now that GIMP handles registration of the same menu item from > > different plug-ins, I am just waiting for the time a user reports > > a bug in Whirl and Pinch (for example) and doesn't realize which > > version they were using (as in the Python version or the C > > version). > > The Python version will of course not be in any stable release. > > And so far I don't see anyone complaining about my proposal to not > install any Python scripts at all with GIMP 2.4. Hey. It is allright for me if you do not install then- but I had complained. - At least count that. Actually we could think of then case by case. Almost all of then are just clones of other plugin/scripts, buyt, py-slice, for example, has only an equivalent in gimp-perl, and currently py-slice is far more capable. Also, IRCC, some scripts dealing with palettes where implemented in python, using some I had done as basis. These also provide unique features. 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
[Gimp-developer] Gimp python
In bug #346001, Sven wrote: >Comment #3 from [EMAIL PROTECTED] (GIMP developer, points: 23) > 2006-06-27 13:47 UTC [reply] > If you ask me, Python-Fu must not install any plug-ins at all > as long as the user interface doesn't hold up to our standards. This > includes complete internationalization and localization. I suggest > that we disable installation of Python plug-ins for the 2.4 > release. (http://bugzilla.gnome.org/show_bug.cgi?id=346001) I consider this both sad and grave. IMHO, the build of python-fu by default, and support for it under Redmond OS is one of the greatest things in this development cycle. I will undertake i18n of the python-fu then, with no delays. What else do you consider important for the UI to have for it to keep up with gimp standards? Regards, JS -><- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Mask to selection
On Tuesday 27 June 2006 10:41 pm, sampin wrote: > Hallo, > > does there exist a "mask to selection" function that can be called > from within a plug-in? > Have I missed it in gimp api? > Hi sampin, Use "gimp-selection-load". 'masks' count as 'channels' for gimp-internals purposes. > Thank you > Ollie > ___ > 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] menu cluttage
Hi, I e mentioned once or two that when the script-fu and python-fu scripts where brought togetehr to teh same menu space as the C filters there would be confusion about which menu entry is associated with a script in which language. I have been normally replied that "it does not matter" for the end user in which language the script is in. Well...it _does_ matter. The specif\c language matters little, but there are some side-effects. Knowing which package brought which filter is more still important (and also impossible in the current "everything mixed" system) Now I just stumbled into an 'interesting' bug arising from this confusion: Python-fu Whirl and Pinch had overwritten the menu entry for C Whirl and Pinch (moreover Python whirl and pinch is currently crashing) Please notice there is no way a normal user can be aware of situations like this. Actually, it is almost as annoying (to say the least) as win95 and beyond "feature" of not showing the image file extensions in the file browsers. But even win95 has different icons for different kinds of images. The GIMP currently has just no clue. SO, I am bringing this subject to discussion once more, and asking about adding a small icon to menu entries, or some other indicator to tell users which entry came from where. Regards, JS -><- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Getting the GIMP to work well on a OLPC laptop
On Tuesday 06 June 2006 12:25 pm, Dave Neary wrote: > Hi, > > As the SoC administrators probably know, the OLPC project is > entering a phase soon, where they will be making a very limited > amount of laptops (no more than 1 per project requesting) to free > software application developers. > > I thought maybe someone here might be interested in getting one, > and would have the time to do profiling and memory work with a > small screen laptop to reduce the footprint and increase the speed > of the GIMP in that kind of environment. One other constraint, you > don't have any (or much) hard disk - swapping times out is an > expensive operation. > > Is anyone interested? If you don't have time to spend on this, the > greater good is probably best served by letting another project > have one, but it would be great to have a faster smaller GIMP. > > Cheers, > Dave. Let's put it in these terms: Pippin? can that stuff run a washed out GIMP or Horizon? What do you think about matching it against the 770? JS -><- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp-python: Artefacts when creating layer
On Sunday 04 June 2006 02:45 pm, Sven Neumann wrote: > Hi, > > On Sat, 2006-06-03 at 11:58 -0300, Joao S. O. Bueno Calligaris wrote: > > For C plug-ins that might be true. However, python plug-ins are > > not good in dealing directly with pixels - that is, for rendering > > things. > > There is no need to access pixels directly. We are not asking the C > programmer to iterate over the pixels and clear them directly. > Calling gimp-drawable-fill is sufficient, no matter what language > binding is being used. That was not what I meant anyway. The matter is: the only advantadge of not having a layer automatically cleared when it is created, is sparing somw cycles if you are generating the layers content. Generate the layers content from within thew python code is something that, although can be done, is so slow, that the time spent auto-clearing the table becomes negligible. It may look as a single extra line of code for us. For one trying with the scripts, it is one more "secret" to be found or overcame, that might not take negligible time. That is the motive for my suggestion. 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] Re: New microsoft image format
On Saturday 03 June 2006 05:49 am, Juhana Sadeharju wrote: > Now to the quoted text. > In my software, I have already thought of using a license > which forbids their use in Windows. I don't know the license > details yet; perhaps GPL + restriction. > > The major point is that domestic computers are sold with Windows > preinstalled. I have not seen a domestic computer sold both with > Windows and Linux, or with Linux only. This is not entirely about > what people want: the Windows typically is ripped-down version > which comes with ripped-down, bannered versions of software. The > system is barely usable as standalone (not usable if you ask my > opinion). Just to stand the point: here they are starting to sell computers with linux only on the low end market. It is a step forward, but smaller than it looks like. Salesperson thenselves offer to install pirated windows versions on these computers for a small fee, for example. On the other hand some of the vendors thenselves make such a crappy install of Linux that no one can handle using it. Linux Magazine Brasil tested a low end machine by HP that came with 128MB RAM and 1GB Swap space. The result: OpenOffice would take full 3 min. to start! And now, leaving this subject and back on what the main thread become: I am just finishing a 4 month course on the GIMP for people wiht little knowledge on computers and little wealth. All of then run Windows , if they have PC's - and if the GIMP did not run on windows, they'd have to be using some other software athome instead of the gimp. But, step by step we are getting there. Regards, JS -><- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp-python: Artefacts when creating layer
On Saturday 03 June 2006 09:53 am, Simon Budig wrote: > Alan Horkan ([EMAIL PROTECTED]) wrote: > > On Sat, 3 Jun 2006, Simon Budig wrote: > > > That sounds as if you don't clear the layer before you use it > > > for the first time. Layers created from a Plugin are not > > > initialized from the very beginning. They need to be cleared > > > using e.g. gimp_drawable_fill. > > > > I remember getting caught out by this too. Why is necessary to > > manually clear a new layer rather than have it done > > automatically? > > I have no strong opinions on that. I guess the reasoning behind > this behaviour was a speed optimization: If a plugin later renders > stuff to a new layer anyway it would be a waste of time to clear it > automatically. If it doesn't it would just invoke > gimp_drawable_fill. No harm done, except that you have to know > about it. > > It might even matter for big images... > For C plug-ins that might be true. However, python plug-ins are not good in dealing directly with pixels - that is, for rendering things. I guess the python api for creating a layer could create an empty one with no problems. Regards, JS -><- > Bye, > Simon ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] New microsoft image format
Just missing the deadline for a SoC sponsored plugin for it, microsoft released the specs for their new image file format here: http://www.microsoft.com/whdc/xps/wmphoto.mspx I di dnot download it, bu I read the agreement for ownlaoding it. One keep his soul and his mother in doing so. I mean- there is no nasty NDA, it seems possible to implement a free software as fara s copyright issues stand, for reading and writing the beast - but the nDA says that software patents involving that owned by MS still apply. They announce a lot of miracles for this format, and it would be nice to be able to read and write to it if half of then hold true. JS -><- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Suggestion: Make the 'New layer' command defaultto 'New lay
On Wednesday 17 May 2006 08:40 am, Martin Nordholts wrote: > One other alternative be to provide a key-shortcut which would > create a new layer with the previous properties, which part of "hold shift" in my e-mail was that hard to understand? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Suggestion: Make the 'New layer' command default to 'New layer with last values'
inestead of that hold shift ! it has been dthe default through the 2.0 series, and it was not firendly to novies. You just hold shift whenpressing the new layer button. thank you for your interest, an dyou are welcome to more suggestions. But this one is not a bug. On Wednesday 17 May 2006 04:17 am, Martin Nordholts wrote: > Hi Everyone! > > It's me, the Xtns -> Extensions guy if you remember. > > I've been using GIMP over the last months to really get to know it, > and I must admit that the workflow improves dramatically once you > start to really get into the UI. > > I have however noticed one thing that I think could be improved. > I've found myself using the 'New layer' command on the 'Layers' > window quite often, and it is very rare that I want to change the > properties of the layer. (The absolute most frequenty > new-layer-command is 'create a new transparent layer the same size > as the image'). > > I propose a small change to the code. Since it is very few lines, I > thought that creating a .diff file would be overkill, so I'll just > write the changes here: > > In gimp-2.3.8/app/widgets/gimplayertreeview.c swap place of the new > layer callbacks so it becomes this: > > item_view_class->new_action = "layers-new-last-values"; > item_view_class->new_default_action = "layers-new"; > > In gimp-2.3.8/app/actions/layers-actions.c, make > layers_new_last_vals_cmd_callback() be invoked when > N is pressed (instead of > layers_new_cmd_callback()). > > If you need this as a formal patch, let me know and I'll create > one. > > IMO this improves the workflow futher. > > /Martin Nordholts > > _ > För dig som älskar spel http://www.msn.se/noje/spel/ > > ___ > 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] Gimp certification
On Friday 12 May 2006 02:30 pm, Olafur Arason wrote: > I think Gimp should have something like Adobe Certified Expert. Well... I don't. > This would ensure that gimp trained individuals could show > that they know Gimp like it's possible to test what you know > about Photoshop. > This test should be hard, but not it the memorize everything > kind of hard, this would be to ensure that people that get > this degree actually know something about Gimp. > What would you think a person with this degree should > know? > Is anybody on this list willing to participate in this? > Is certification such a bad idea that Gimp should > associate it self with it? > IMHO it is. > LPI is interested, but there is nothing definite > > Olafur Arason > P.S Please don't say it takes to much time, making true color > management work in Gimp also takes time but I don't see > anybody say that we should not do it because of that. I see it from this POV: what does the World gain with more bureaucracy in it? If I need to contract someone to work on GIMP or another Image Manipulation program, I will sit him in front of a computer and watch him draw. Besides that, certifications are sometimes sought for those without the abilities or application to stand by themselves, either in their C.V. or personally. I dislike the idea of a GIMP certification - and please note that I could make a lot of money out of it, as I certainly would be entitled to teach courses for, and concede such certifications in my country. JS -><- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Time or velocity info [Re: SOC - brush system]
On Tuesday 09 May 2006 01:52 pm, GSR - FR wrote: > Hi, > > [EMAIL PROTECTED] (2006-05-09 at 1654.44 +0100): > > Joao S. O. Bueno Calligaris wrote: > > > On Monday 08 May 2006 10:51 pm, GSR - FR wrote: > > >> That reminds me another parameter, velocity (or time delta, it > > >> is related) and that airbrush had issues with high speed... > > >> anybody knows the exact definition and use of > > >> gimp_paint_core_paint's guint32 time (I traced to > > >> http://developer.gimp.org/api/2.0/app/GimpPaintCore.html but > > >> says nothing)? > > > > > > I tried to fiddle with it once (implementing speed as a way to > > > select the frame of animated brushes), and got mostly lost > > > myself. All I know is that the ink tool has a different > > > implementation that does "time smoothing" or something to > > > interpolate the gtk+ event time. > > [...] > > > I don't think that any other brushes at the time were velocity- > > sensitive (are they now?), hence the private implementation. > > Animated brushes can be saved with such config... but it does > nothing as it is not implemented publicly, so I guess anybody that > tries the setting just gives up and saves with any of the other > options from the drop downs. Hmm.it does now - the patcjh for it has been comited some months ago - but, it doe slittle- not very usefull without a callibration curve and a way to smooth down the time coordinates, just as the paint tool does. > > The other use case for using the time is the airbrush. I looked at > it time ago and looked again due this thread, first idea was > checking the remaining of airbrush timer, but there seems to be > none (yet?). It is required as airbrush stamps every X time, but if > you move faster, the effect of time is ignored, getting stronger > stampings than what really should happen. > > So no, there is no current use of velocity, but just cos it is not > implemented, and thus nobody thinks about possible uses. Sounds a > bit recursive. ;] Ok - there is a velocity setting on the animated brushes, so we broke the recursion...we just need a volunteer to factor out the ink tool use of it, and implement a velocity calibration curve for the strokes. :-) > > GSR > > ___ > 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] Time or velocity info [Re: SOC - brush system]
On Monday 08 May 2006 10:51 pm, GSR - FR wrote: > Hi, > > [EMAIL PROTECTED] (2006-05-09 at 0245.34 +0200): > > Actually the vector objects already store GimpCoords at the > > control points and hopefully the code already interpolates them > > properly. This is all totally untested though, since there is no > > real way to control the additional parameters (pressure, xtilt, > > ytilt, angle). > > That reminds me another parameter, velocity (or time delta, it is > related) and that airbrush had issues with high speed... anybody > knows the exact definition and use of gimp_paint_core_paint's > guint32 time (I traced to > http://developer.gimp.org/api/2.0/app/GimpPaintCore.html but says > nothing)? > I tried to fiddle with it once (implementing speed as a way to select the frame of animated brushes), and got mostly lost myself. All I know is that the ink tool has a different implementation that does "time smoothing" or something to interpolate the gtk+ event time. > GSR > > ___ > 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] gimp with large files. test.
On Monday 01 May 2006 11:37 am, Campbell Barton wrote: > On the other hand, Photoshop may be working on a smaller copy of > the image at 1:1, > has this been considered by the gimp dev's? it most certainly does, and then does the real curves work on the background. Considered? Yes. Made? No. Nowadays it is sort of postponed until after 2.4 is released and GeGL starts to be integrated into the GIMP. I think one of the great bennefits of GeGL will be allowing doing this kind of live previews with transparent background processing - Although that will not come for free with the GeGL. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Project proposal: Resource contribution, distribution and management system
On Monday 17 April 2006 04:58 pm, Michael Schumacher wrote: > Bill Skaggs, who volunteered to be the organization administrator, ^^^ /me smiles evilly! > has already written a draft of the application mail. We want Sven > or Mitch to have a look at it before it is sent. There are also > some other project proposals, which are supposed to be presented > here this week. > > > HTH, > Michael ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Bring Back the Keyboard!
On Wednesday 15 February 2006 10:42 am, Robert L Krawitz wrote: >From: Leon Brooks <[EMAIL PROTECTED]> >Date: Wed, 15 Feb 2006 18:28:22 +0800 > >On Wednesday 15 February 2006 16:18, Sven Neumann wrote: >> The user should never ever have to do this. We need to either >> move some of our resource files into a visible folder or we >> need to provide a user interface to manage resource files that >> doesn't involve using a file manager. > >All of which sounds like _much_ more work (and many more design >decisions) than simply making the file selector work > consistently. > > Not to mention that someone might want to edit files in a hidden > directory for other reasons (e. g. thumbnail files stored in > .thumbnails). Actually, my problems begun in gedit - I was editing a python script, and certainly, for people on GNU/Linux for the first time, EMACS would not be a suitable option. GIMPwise, Sven's suggestions are ok. I like more the idea of actually unhiding the gimp profile directory. Because a separate interface to save images that are to be saved as patterns or brushes, IMHO, would only break things even more. A bookmark to the gimp profile would also work. Of the things accessible through other interfaces, I think there is little left to be done. JS -><- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Bring Back the Keyboard!
On Tuesday 14 February 2006 06:00 am, Sven Neumann wrote: > Hi, > > Scott <[EMAIL PROTECTED]> writes: > > Haven't had time to extensively check out the newest version, and > > I'm sure it has a lot of nifty new features: BUT one think that > > irks me right away is not having any option to type in a filename > > on the 'open' dialogue! > > There is nothing that keeps you from typing a filename in the file > open dialog. Perhaps you should just give it a try one day. But, > and I think this has already been pointed out, this is something > that you should sort out with the GTK+ developers. > Unless, of course, the filename is in the ~/.gimp-2.x dir and you try to getthere by start typing "." I am serious about this: I _lost_ almost 20 minutes in a 3 hour workshop trying to get people to open files in ~/.gimp-2.x - and after that I still had to try to explain why ctrl+l + ".gimp-2.2" + would work, and ".gimp-2.2" + , although displaying something would do nothing. Most people windows users for the first time using a GNU/Linux desktop. I guess they won't come be coming back any soon now. I think it is quite clear by now that this lack of a visible place to type a filename is damaging to both all of gnome, the Gimp, and in situations like the above, to the whole Free Software movement. The current "transparent type" hack simply does not work as it should - if it should at all. Regards, Joao > > 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] Plugin brush tool
On Friday 27 January 2006 04:38 am, Rob Krajcarski wrote: > I spent most of today trying to accomplish this type of plugin > within photoshop, only to find out that it was not possible...so, > I'd rather not have to go through the same thing with Gimp > tomorrow.. > > In general what i'd like to accomplish is the following: > > -poll the position of the brush on the canvas, or even better would > be to receive notifications as to the position of the brush as it > moves -using this historical position to mathematically calculate a > specific colour to use for the brush > > Ideally I'd like to be able to just change the foreground colour of > the brush, but still preserve artists ability to use different > brush heads, opacties, etc... > > So, just thought I'd be a bit more explicit in what I'm trying to > accomplish before I jump into the code. > > Please let me know if there's reason to believe that I won't be > able to accomplish this kind of plugin without making changes > throughout the core codebase. > > Thanks > > Rob > Hi. I've thoguht of similar things before, but I was turned down. I'd still likle to have this ability, so maybe if you find no other way, you could came back here, and then we could try to attach something to the core. The bug-report where I suggested and discussed such a feature is here: http://bugzilla.gnome.org/show_bug.cgi?id=140165 Regards, JS -><- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] python plugin
On Monday 16 January 2006 12:10 pm, Emanuele Zattin wrote:
> Hello everybody,
> my name is Emanuele Zattin and i'm developing a plug-in
> implementing a texture synthesis algorithm described in a paper
> ("Texture Synthesis by Non-parametric sampling" by Efros and
> Leung).
> Here attached you can see my actual implementation which works on
> grayscale images. It is anyway VERY slow, which was anyway
> predictable judging from the complexity of the algorithm.
> I was wondering if translating it to C would make it much faster or
> if there are some more speedup techniques i'm just missing.
>
> Thank you very much!!
>
> Emanuele Zattin
Hi Emanuele,
The default way for accessing pixels from python plug-ins is slow.
I started researching a faster way a while back, but halted. i think
it is important.
I don't have teh time now to check if this is the problem in your
cscrpit, but from my previous experience, it is rather likely.
I will take a look at it later, and suggest another way to manipulate
the pixels if possible (or if not possible, seeing what can be done
on the gimp-python bindings themselves).
Either way, since you already use Numeric, going to C won't be
necessary (unless I fail to do all of the above).
Regards,
JS
-><-
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Patterns
On Wednesday 28 December 2005 08:59 pm, Leon Brooks wrote: > On Thursday 29 December 2005 02:25, Alexandre Prokoudine wrote: > > Another solution would be providing a separate package of new > > high-quality textures. > > Are any of these useful, at least as a starting point? > > http://www.burningwell.org/gallery/textures > > Cheers; Leon Hi Leon! Yes, most of these are very nice - and show samples of what a good collection should have...but indeed, seeing these, one has to conclude that a more efficient way to handle textures has to be coded in the GIMP. AFAIK, the current handling of patterns loads them all to memory. JS -><- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Patterns
I was looking at the patterns that come with the GIMP. They might have been nice for 320x240 web images that everyone edited a few years ago. But in a world of 7 MP cameras, all patterns that come with the GIMP are nearly useless. there are a few pending features for patterns on the program itself - like categorization, possibly scaling, and so on. That aside, these patterns are in urgent need for an update. Even if not on the patterns that come along with the GIMP itself, nice pattern collections would be nice - perhaps some that could be packaged in a "gimp-data-extras" module, or something like that. Even updates of the existing patterns so that they do no look a silly square repetition when covering a surface more than 400px wide would be a nice thing. So - developers, what do you think might be the best approach? To update the patterns that come with the program thenselves or make additional collections available? And everybody - let's start building some nice patterns - one way or the other we have to collect then all an make then available for all the GIMP users. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] P.S.
On Sunday 11 December 2005 07:56 pm, Chris Share wrote: > That would be very helpful for newbies like me. > > Cheers, > > Chris > Maybe you'd find it more easy to make the move once for all. A GNU/Linux desktop is developer friendly, besides being user friendly. There are a handfull of choices you could try not even having to perform a hard drive install (although you hardly could get to build GIMP one withtout installing things to hardware. But it certainly will be much easier to build the GIMP and plug-ins in a freshly installed GNU/Linux than hunt for all dependencies and workarounds needed under windows. You could try getting yourself a UBUNTU CD, for example (you can order then for free at shipit.ubuntu.org, but there would be faster ways for you to get then), or some other distribution that you could get a nearby friend to help you with. Most distributions are downloadable for free at all. Sorry if this seems O.T. but I am really interested in heling you, and I do not think that holding back to windows is a good way to start. JS -><- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Path tool and plug-ins?
Indeed, the Paths itnernals and UI was completly revamped on GIMP 2.0,
but the API never catched on.
There is no way to work properly with multple component paths with the
current API, as you had found out.
I cannot give further advise at gthis moemnt, but to ask politely for
you to take a look at the source. Tehre is a bug report dealing with
this in GIMP's bugzilla, but there is nothing serious there.
Apart from that, we have to wait for Simon to step him, and give some
hints (he redesigned the vector internals for 2.0). Either way, you
will be better able to follow his suggestions if you had already
taken a look at the source.
Regards!!
JS
-><-
On Tuesday 25 October 2005 02:32 pm, Matteo Quintiliani wrote:
> Dears all,
> I'm developing an open source plug-in capable of vectorise
> historical seismograms.
> http://registry.gimp.org/list?name=teseo
> http://sismos.ingv.it/teseo/
>
> Using function gimp_vectors_compat_get_points() with a path that
> have more than one component, I get the following message:
> Gimp-Vectors-WARNING **: gimp_vectors_compat_get_points(): convert
> failed"
>
> I took a look in gimp-2.2.8/app/vectors/gimpvectors-compat.c line
> 164 of 281, and I was very surprised reading:
>
> ===
> if (open_count >= 2)
> {
>g_warning ("gimp_vectors_compat_get_points():
> convert failed");
>*n_points = 0;
>return NULL;
> }
>
> ===
>
> Has someone planned to extend this function?
> If not, could someone provide me further information to do this?
> I'll be very happy to help in gimp development.
>
> Sincerely,
> Matteo Quintiliani
> ___
> Gimp-developer mailing list
> Gimp-developer@lists.xcf.berkeley.edu
> http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Question about the plug-in system.
On a note to my previous idea of linking such a script to Blender3D: If it is not possible for a script to be both a GIMP plugina a blender script, anyway, a Bldenr Python Script can comunicate with a GIMP plugin script via sockets or TCP with very little effort. The major nuisance I see in this aproach is taht AFAIK blender takes full screen for it, so I do not know you could keep a GIMP window open over Blender for painting. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Question about the plug-in system.
On Thursday 04 August 2005 18:43, Axel Philipsenburg wrote: > Hello folks! > > I've just now joined this mailing list, looking for some info from > people who know the internals of the Gimp's plug-in system. > > The reason is, that I have a project in mind that I'd like to try > to write as an Gimp plug-in, but I am not sure if it can be done. > > So before diving headlong into the source I though I'd rather ask > if it's even doable. If so, then I'll start digging through docs > and code. :) > > What I'd like to do is to write a plug-in that would make the Gimp > a nice tool for 3D artists by showing a 3D object in a seperate > window with the currently selected Gimp image as UV mapped texture. > > The 3D object would be loaded from a Wavefront OBJ file with all UV > mapping coordinates and been displayed by using OpenGL. > > The only thing that gives me worries about this, is if the Gimp > plug-in system would allow a seperate window to be constantly > displayed and updated whenever a tool operation is finished so that > the artist can practically see each brush stroke (or other tool > usage) instantly on the 3D object once the tool has been used. > > If that is the case, then the only real work for the plug-in in > would be to make a flattened copy of the currently edited image and > send it as texture to the OpenGL part of the plug-in. > > Any comments on the idea or if this possible with using the Gimp's > plug-in system? > Hi! Offically it is not possible. That is: there is no way for the GIMP to call back your plug-in whenever an action is performed. However nothing but the extreme deselegance of it can stop your plug-in of pooling the GIMP for image data every few seconds. So, I'd say it is feasible. It won't be perfect, but would be functional enough. Are you writing the 3D part? Maybe it is even possible to use blender for it. I do not know exactly how Python works with Blender - but it may be possible to write a script that is _both_ a blender script and a GIMP plug-in and get this working with less than 200 lines of code. JS -><- > Thanks a lot in advance. > > Bye Bye > > Axel > ___ > Gimp-developer mailing list > Gimp-developer@lists.xcf.berkeley.edu > http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New Colors toplevel menu
On Monday 01 August 2005 13:01, Akkana Peck wrote: > Joao S. O. Bueno Calligaris writes: > > I am not so sure about Image->Modes , unless tehre is a ubmenu > > Colors->Image to indicate taht thos ewill operate ont eh whole > > image instead of a drawable. But then, they could just stay were > > they are. > > How about calling it "Image Mode" rather than just "Mode"? > That would be reasonable as far as I am concerned. > ...Akkana > ___ > Gimp-developer mailing list > Gimp-developer@lists.xcf.berkeley.edu > http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New Colors toplevel menu
I am fine with Layers Colors and FIlters integration, if submenus are used in an efficeint way. I am not so sure about Image->Modes , unless tehre is a ubmenu Colors->Image to indicate taht thos ewill operate ont eh whole image instead of a drawable. But then, they could just stay were they are. JS -><- On Monday 01 August 2005 02:20, Akkana Peck wrote: > I've posted a patch to bug 116145 which would move all the color > operations -- currently in Image/Mode, Layers/Colors, and > Filters/Colors -- to a new top-level menu called Colors. > (See the bug for the request and discussion of that.) > > If I don't hear any objections I'll commit it in a day or so. > > One issue is that it makes for an awfully long menu (see screenshot > attached to the bug). Probably some of the items in it should be > moved to a submenu -- e.g. move everything that was previously in > Filters->Colors to Colors->Filters? Please post any suggestions > here or in the bug. > > ...Akkana > ___ > Gimp-developer mailing list > Gimp-developer@lists.xcf.berkeley.edu > http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Snap To Canvas
On Tuesday 12 July 2005 08:16, Michael Natterer wrote: > On Mon, 2005-07-11 at 22:59 -0500, Tim E. Jedlicka - wrk wrote: > > I'm running gimp-2.3.2. Thank you for the "snap to canvas edge" > > option. I would suggest that it should default to "on/checked". > > Snap to Guides is defaulted to "on", the canvas edge should be > > considered a default guide (in fact, that is how I would > > implement the feature, have images open with the edge being the > > default guides - but since I'm not a coder I'm just thankful for > > the feature regardless how implemented). > > > > If a user does not want the snap to's defaulted to "on", they can > > change the snap pixels to 0 (or 1?) in preferences and accomplish > > the equivalent behavior. > > Hi, > > you have a point here. IMHO we should change this to snap by > default. Would you file a bug about this so it's not forgotten? EEEKkkk! Beware there: while snapping layers to the canvas on by default would be good, the option also snaps paint strokes!! That is _not_ good to be on by default - one goes carefully painting with the paintbrush, and suddenly it is sucked to the edge, out of nowhere!! > > (go to http://bugs.gimp.org/) > > thanks, > --mitch > > ___ > Gimp-developer mailing list > Gimp-developer@lists.xcf.berkeley.edu > http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Layer locking proposal
On Sunday 26 June 2005 17:48, Sven Neumann wrote: > Hi, > > "Joao S. O. Bueno Calligaris" <[EMAIL PROTECTED]> writes: > >> If we want to have all the lock types that PS offers, we would > >> have to add three new toggles to the layer row. Is that > >> feasible? > > > > kkk... > > I thought of three different states for the lock Icon (and a > > nice tooltip, of course). > > Three lock types make up for 2^3 states. Not sure if all of them > are useful but it could become difficult to display all useful > states in a single icon. Oh well, as Homer Simpson would say: DOH! :-) What about a drop-down menu there? The icon would display an open lock - or nothing at all. When clicked, a drop down contest menu with check itens for each "locking" option would appear. If any of the locking options would be picked, the icon would ebcome a locked bolt. Clicking on it, would make the drop-down menu to show up revealing the state of the layer. This UI could even be used to the linked state as well, therefore resoving the space problem. I do not have the time to elaborate a mock up on this, so I will explain the idea again, with a different wording: On left-clicking on the layer-tree, where the current "linked" icon for each layer is placed, a drop-down menu would be displayed. This menu would contain 4 itens which could each be checked or unchecked: Transparency Lock Color Lock Geometry Lock Linked - If either of these get checked, an apropriate icon (which could be always the same) would displayed in that place. -- IMHO, the idea of other specific contest menus on the layers tree may be needed anyway when layer grouping is included - There will simply be more options than the current UI can deal with. > > > Sven > ___ > Gimp-developer mailing list > Gimp-developer@lists.xcf.berkeley.edu > http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Layer locking proposal
On Sunday 26 June 2005 13:48, Sven Neumann wrote: > Hi, > Well, it is up to the user to name the layers and I don't think we > should make it harder to use long names. In general it is better to > allow list views to scroll horizontally instead of trying to > shorten the content to make it fit into the dialog. > > If we want to have all the lock types that PS offers, we would have > to add three new toggles to the layer row. Is that feasible? > kkk... I thought of three different states for the lock Icon (and a nice tooltip, of course). JS -><- > > Sven > ___ > Gimp-developer mailing list > Gimp-developer@lists.xcf.berkeley.edu > http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] pygimp on windows? success!
On Sunday 26 June 2005 11:19, Michael Schumacher wrote: > lode leroy wrote: > > Ah, now it starts up, and the "Python-fu" is there... yippee! > > It should do so now out of the box, at least in current CVS... > maybe except for the interp file, but we should be able to fix this > today. > Horraayy!!! :-) >(...) > Thanks again for your input! > > If you want to continue to work on scripting, and get even more > scripting languages to GIMP on the windows plattform, there is > gimp-perl, some java classes, a ruby binding and iirc even > something for Tcl... :) And there was the guy asking for a Lua interpreter, and I rememeber someone was working on GIMP-C# > > > Michael ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Patterns tab
On Friday 24 June 2005 10:02, nuno alexandre wrote: > Hi, > I got a request, I hope that request are welcome in this list. > I'd like to have the possibility to organize the patterns tab into > classes. > for example: > patterns -> > > clouds > > grain > > metals > > etc..etc.. > > Maybe this is possible, and I'm not aware of it? > Sven sent a detailed plan to do this as soon as 2.2 was released. Unfortunattely, as far as I know no one is implementing that. (The palane including making categories for both Patterns, Palettes, Brushes, Gradients and Fonts). Maybe we should at least paste that e-mail into an enhancement request in bugzilla so it is not lost? Does anyone have it around? JS -><- > Thanks, > > nuno ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] About Preferences enrtry in the Edit menu
On Thursday 23 June 2005 17:22, Michael Schumacher wrote: > Joao S. O. Bueno Calligaris wrote: > > It just feels great. > > > > I t always took me sometime when pointing someone to Preferences > > to go to "->FIles->Preferences" and not > > "->File..." > > Well, unfortunately this seems to lead back to the "Why the heck do > I have to open an image to access $feature?" times... and I thought > these were finally gone. Why so? The Preferences entry is still in the ->File menu. One other possible rearangement would be drop the "dialogs" and "prefences" entries into "Xtns" and rename that to "Extras" once for all. > > > Michael ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] About Preferences enrtry in the Edit menu
It just feels great. I t always took me sometime when pointing someone to Preferences to go to "->FIles->Preferences" and not "->File..." Thanx Sven! ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP
On Tuesday 21 June 2005 20:30, Sven Neumann wrote: > If you just add an entry to the current dialog you don't get the > current dialog with the extra benefit of an entry with Tab > completion. Unfortunately what you get is a dialog that has two > orthogonal ways of navigating it with the keyboard and both ways > keep getting into the way of each other. > > Ok - What about this: Hitting the "easy and intuitive" CTRL + L, instead of cluttering everything else with a pop-up, make such an entry field to appear, with focus in it? Therefore, nothing else would be on the way of one who can spend about a minute or two navigating the file structure and clicking on a file, while thos eint he know cna hit ctrl+L for soemthing actually usefull. Joao ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP
On Friday 17 June 2005 18:11, Sven Neumann wrote: > Hi, > > > GIMP is not a GNOME application, it uses GTK+, the GIMP toolkit. > This is by chance the same toolkit that GNOME uses, so integration > with GNOME is easier to achieve. That doesn't mean though that we > wouldn't try to make GIMP work well on KDE. GIMP supports most of > the cross-platform specs that the KDE and GNOME people are > developing to make this happen. What is missing to achieve better > KDE integration is someone who tests GIMP on KDE, gives feedback > and points out what's working and where there are problems. > I actually run the GIMP on KDE, and it works just fine. Minor bug related to KDE integration are reported form time to time to bugzilla, and that is all there is that doesn't work. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp Marbled Paper Bounty?
Hi! Please check if http://hopey.nervo.org/~gwidion/marble_1.png is close to what you want. And tell me whether you have pygimp (Shows up as a Python-fu menu option) installed. Regards, JS -><- On Wednesday 15 June 2005 17:23, Giles wrote: > Hello. > > As I alluded in a previous message, there's a reason I'm lurking > about on the gimp-developer list and it isn't that I'm a gimp > developer. I've used Linux since 1994, and the GIMP for ... > several years. Not sure how long. > > In 2003 I went to Venice and fell in love with marbled papers. I > would really like to be able to recreate those papers with the > Gimp, preferably with wrap so they would tile. There are some > parts of the process that you can pull off with the Gimp as it is > now, and some you can't. > > The best book I've found on the process is this one: > > Marbling Paper and Fabric by Carol Taylor, 1990. Sterling, New > York. > > Unfortunately I haven't found a good photographic record of the > process of creating marbled paper online. There are plenty of > other books though. You can see examples of marbled paper at > http://www.gilesorr.com/Venice/marbled/ - these are scans of part > of each of the papers I brought back with me. You could also take > a look at what I consider two of my more successful Gimp attempts: > > http://www.gilesorr.com/images/200305/VenetianMarble05.html > http://www.gilesorr.com/images/200305/SlideUpwards02.html > > Or just look at that whole lot, > http://www.gilesorr.com/images/200305/ to see a bunch of my Gimp > tiles and a lot of not-so-good marbled paper attempts. > > The parts of the process that would need to be recreated in Gimp > plugins follow: > > - adding paint - essentially localized spraying/spotting (different > size of dots, not perfect circles, random scatter) > - some way to vary brush size (ie amount of paint, size of dots) > - needs wrap > - since it's paint on size (a form of paste on top of the water), > it needs to _push_ other dots rather than just overlaying them > - combing (or single stylus) > - I would like wrap, stroke path, and by hand > - specialized combs - boquet comb in particular, two rows of > alternating teeth > - again, the way it pulls the paint should mimic the physical > world - shaking the tray > - blowing on it as with suminagashi (http://www.suminagashi.com/ - > this process isn't a priority for me) > > I've been planning to offer a bounty for this, but my $50 is > sounding fairly small compared to the recently posted Gnome > bounties. I assume the Gnome bounty code is released GPL, and > that's what I'd expect here. > > So, questions: is anyone interested in working on this? Should I > separate the parts and offer bounties (they'd have to be smaller) > on each of the individual parts? How could all of this be handled? > Is there somewhere else I should post a request like this? > > -- > Giles [EMAIL PROTECTED] > http://www.gilesorr.com/ > -- > > ___ > Gimp-developer mailing list > Gimp-developer@lists.xcf.berkeley.edu > http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] New alignment tool
Hi, I had played with the alignent toll a while, and here is my feedback: - It really feels like going together with the move tool. When selecting a "target layer", one just tries to drag it - no help doing it otherwise. - Once a "reference layer is set, if moving the target layer is possible, it feels natural that it should snap to the reference layer - thus allowing aligning the left edge of the target layer with the right edge of the reference layer, and further snap so that both tops, or both bottons are in the same coordinates. That would feel great, and there is no need for further UI elements. Regards, JS -><- ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: Akanna Menu patch [was Re: [Gimp-developer] The GUADEC meeting]
On Tuesday 07 June 2005 09:53, Alan Horkan wrote: > I was thinking fo doing something similar for the python plugins > (and making sure to add ellipses where needed). However some of > the python plugins duplicate existing functionality so putting two > Clothify plugins beside each other would only confuse users. I see > Akkanna tackled this by marking the Script-Fu unsharp as "Unsharp > 2" but if people have idea on how to tackle this duplication of > functionality I would be interested to hear it. (I must say when it > comes to learning to port scripts to python I found it very helpful > to have similar examples written in a different language) plugin > written . One possible way to disambiguate similar plugins might > be to give them different menu icons but expect you can probably > come up with something better than that. > I always saidthat tehere should be some way to identificate a menu entry. Not only there will be up to four (C, script-fu, Python-fu, tiny-fu) equivalent entries on a row, as you point out - but I think one has the right to know how each menu entry got there. Today it already happens with stuff like 'filter all layers', installed with Gimp-GAP - one can't know where it came from. People suggested that an icon before menu entries would cause to much hassle to the UI - and I agree. I suggested them that right-clicking on a menu item would bring some information about it. (Like: the package where it came from, what language it is written in, and maybe even accept a new shortcut for that item, without having to enable "dynamic shortcuts") Regards, JS -><- > Sincerely > > Alan Horkan > http://advogato.org/person/AlanHorkan/ > > ___ > Gimp-developer mailing list > Gimp-developer@lists.xcf.berkeley.edu > http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Apply palette to image colormap
On Wednesday 01 June 2005 00:03, Kevin Cozens wrote: > Joao S. O. Bueno Calligaris wrote: > >It seems this fucntionality exists in other programs but not in > > the GIMP - i.e.: the ability to apply a palette to an already > > indexed image, keeping the color numbers. > > > >This is easily doable in script, but it could also be done in the > > core > > One of the scripts in Tiny-Fu is called tiny-fu-set-cmap.sct and > provides the functionality you are talking about. I think it is a > feature useful enough that it should be included as part of the > core. It would also run a lot faster than my scripted version. Ah..thre it is. Anyway - the person needing this right now is on win32 - Will this script work in script-fu? And... it is buggy. It failed me when applying 256 color palette to a 256 colro image with the message: --- Error while executing (tiny-fu-set-cmap 6 12 "Gold") Error: car: argument 1 must be: pair -- Not to mention: WARNING: Plug-In "tiny-fu" (/usr/local/lib/gimp/2.0/plug-ins/tiny-fu) called deprecated procedure 'gimp_image_set_cmap'. It should call 'gimp_image_set_colormap' instead! (ooopss... I remember being the one who asked that this particular procedure got renamed before 2.2 ) ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Apply palette to image colormap
Hi, It seems this fucntionality exists in other programs but not in the GIMP - i.e.: the ability to apply a palette to an already indexed image, keeping the color numbers. This is easily doable in script, but it could also be done in the core (and them DND palettes from the palette to the color map dialog, or to the image window could be made to work). Which solution do you think would be better? Regards, João ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 48 Bit Tiff for the Gimp
On Tuesday 31 May 2005 08:00, Sven Neumann wrote: > Hi, > > You already got in touch with the relevant party. Adding support > for higher color depths to GIMP is on the roadmap and will be > addressed as soon as GIMP 2.4 is done. The plan is to use GEGL > (http://gegl.org/). Part of it has already been written but this > work had been abandoned for a while. Incidentally we only yesterday > decided to pick up work on this library again. Mitch, Pippin and me > will be reviewing and cleaning up the code over the next days. If > you want to help, we can certainly need help in this area. At the > moment I can not really tell you exactly what needs to be done but > I should be able to tell you in a couple of days. HOORAAY!!! That is __great__ news! I f possible I ask that you three post any progresses, and most importantly, specific small tasks that could be done by others, on the GEGL-devel list. Regards, JS -><- > > > Sven > ___ > Gimp-developer mailing list > Gimp-developer@lists.xcf.berkeley.edu > http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] use of the Space key
On Monday 23 May 2005 20:08, Sven Neumann wrote: > Hi, > > Laxminarayan Kamath <[EMAIL PROTECTED]> writes: > > An entire new idea of keystrokes : for the keyboard shortcuts: if > > you press a key the normal way ,it will select the tool > > indefinetely alright. But if the key is pressed and held, and i > > do something, and then release the key, the tool reverts back to > > the one last used. > > Sounds interesting. Probably worth trying. Anyone? I like the idea. I had never looked at this part of the code. I believe that with Gimp contexts it is possible to "push" any tool with the current code already? JS -><- > > > Sven > ___ > Gimp-developer mailing list > Gimp-developer@lists.xcf.berkeley.edu > http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] use of the Space key
Hi, I find the current use of the space key just great. If other image manipul;ation programs fail to do that, that is a lack of functionality on those programs - I see no reason to "downgrade" the GIMP just to get the look and feel of other programs. The panning funcionality on the botton right corner of the image windows works allright for me - maybe there could be a way to let that more visible. OTOH, what about making it configurable? Is it feasible? Regards, joao -><- On Saturday 21 May 2005 12:00, Sven Neumann wrote: > Hi, > > I consider to change what GIMP uses the Space key for and would > like to get some user feedback on this. Currently, pressing the > Space key temporarily switches to the move tool. This is sometimes > convenient but I am not sure if it is all that useful. > > Another image manipulation program, which GIMP is frequently being > compared to, uses the Space key to offer the functionality that > GIMP has bound to the middle mouse button: panning the image > display. Since not everyone has a middle mouse button (especially > on tablet pens), it might be a good idea to follow that example. If > we did that, pressing Space would keep the current tool but the > cursor would change to a hand symbol and one could drag the image > display (not the content!) using the mouse. > > Any opinions on that, anyone? > > > Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Macro recorder?
On Thursday 19 May 2005 03:51, Jan Olof wrote: > Hello! I wonder if the macro recorder will be implemented soon in > Gimp? I guess that it would be good if it generates Scheme script > code. > > It would be very great if there was possible to use a macro on > every picture in the GAP image range. > > Could I contribute in some way? I'm a college educated software > engineer. So... I think this subject could raise back on this list. The last time it was discussed, we had some dependencies on the Undo System for this to be implemented the Right Way (tm). How is that doing today? JS -><- > // Best Regards Jan-Olof Jansson > > ___ > Gimp-developer mailing list > Gimp-developer@lists.xcf.berkeley.edu > http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] help required
On Monday 02 May 2005 15:07, Michael Schumacher wrote: > Rajesh T.S wrote: > > Hi all, > > I am very newly introduced to GIMP. now i need to do 2D image > > rotation and needs to read pixel values at some specified > > coordinates. can anyone guide me in this aspect by pointing to me > > any simple example codes written using GIMP libraries ... > > First advice: > > Configure your mailer to not send HTML and to not attach vcf files. And after the first advice, to answer your question: If all you need is what you describe,m you are in agood position to use the GIMP - Python bindings. You will be at a disvantadge if you are in a non-posix OS, though, as GIMP-Python bindings do not build on this peculiar platform. Just install/compile gimp-python, check the example scripts (sphre.py). If you need to learn python, 20 or 30 minutes at www.gimp.org, pick the links to the tutorial, will do. And them, just check what functions you need from the GIMP's PDB (XTNS->PDB browser) , like the gimp_drawable_get_pixel function. It is not really hard. You can also do similar in scheme and C languages, if you prefer,or even perl. Regards, JS -><- > > > HTH, > Michael ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Alpha compositing
On Wednesday 13 April 2005 21:12, Joao S. O. Bueno Calligaris wrote: > On Tuesday 12 April 2005 13:06, JS wrote: Let's see how far I can MAP these SVG comp. modes to GIMPs: 1) clear: Not available as a composite mode. One might just turn the layers visibility off. 2) src:No mode. Turn off the visibility of the dst layer. 3) dst: No mode. Turn off the visibility of the src layer. 4) src_over: mode "behind" 5) dst_over: mode "normal" 6) src_in: no equivalent mode. There would be needed another (custom) mode mode that would multiply or "lighten only" the alpha component, and ignored the dst color. 7) drc_in: no equivalent mode. There would be needed another mode that would multiply or "lighten only" the alpha component, and ignored the src color. 8) src_out: no equivalent mode. There would be needed another mode that would multiply or "lighten only" srca by the complement of dsta, and ignored the dst color. 9) dst_out: no equivalent mode. There would be needed another mode that would multiply or "lighten only" srca by the complement of dsta, and ignored the dst color. 10) src_atop: no equivalent mode. There would be needed another mode that would be like the current behind mode, but use dsta instead of srca 11) drt_atop: no equivalent mode. There would be needed another mode that would be like the current normal mode, but use srca to replace dsta. 12) src_atop: no equivalent mode. A XOR_alpha mode would be needed to emulate this. Apart of the nice code I pointed in the other e-mail, I have a current python script is flexible enough to easily do these compositions. As a plug-in, however, it doesn't operate in real time: you have to draw you layers, and call the plug-in to generate a resulting layer from the operation. If you are interested I can have it dealing with these 12 modes in a little more than an hour. JS -><- ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Alpha compositing
On Tuesday 12 April 2005 13:06, JS wrote: > Hi, > > I'm trying to locate the alpha compositions code in Gimp and > cannot find it. I've found C/MMX/Altivec versions of many > image-image composition operations but they don't seem to use the > alpha channel at all. > > For example, I wonder wether the "overlay" composition > corresponds to the Porter-Duff "over" operand. I've seen that some > of the Porter-Duff operations are now part of GGGL > (http://pippin.gimp.org/gggl/). I'm a little lost in all this. So I > guess my questions are: > > 1) Does Gimp implement the 12 Porter-Duff operations > (http://www.w3.org/TR/2002/WD-SVG11-20020215/masking.html)? If so, > I guess they must have different names. > 2) Where are the specifications for the compositing functions found > in Gimp (like blend, screen, overlay, etc)? None of these functions > seem to make use of the alpha channel, but is there still a link I > do not see with the Porter-Duff ops? > 3) Where is Gimp heading wrt composition ops? Is GGGL the new > standard? > > Thanks, Hi! The app/paint-funcs/paint-funcs-generic.h. file Bill pointed too is not used anymore - it is there in case someone builds the GIMP disabling aceleration with an option I forgot which is. For the composting functions, take a look in the app/composite directory, in the "gimp-composite-generic.c" file. Some of the functions are acelerated for MMX or SSE in the corresponding files, others are not. As for your question (reading about Porter Duff) wow... comparing 12 kindso oif operations is a lot - but AFAIK the compositing models on the GIMP were not created thinking on these specific Ops. Some may be the same, others certainly are not. http://bugzilla.gnome.org/show 2) There is not a proper Spec. This area of the current Docuemtnation is finding lacking, and there is even a bug openned against the docs. A better description can be found on the older "groking the GIMP" book for some of the modes. Currently, teh best way to know what eachmode does, if the explanation in the above sources does nto suffice, is checking the code in the above file. 3) No. GEGL is not in use yet. As I told, the funciotns are in the app/composite directory. 4) Please, take a look at http://bugzilla.gnome.org/show_bug.cgi?id=161449 for a way to check a cheap way of implementing these new combination modes in a way that would not cluter the GIMP ui. If there is people wanting it working (custom layer modes) , I could go backk to work on it, even making it available to the GIMP if GEGL use is further stalled. 5) Nice name this of yours! Regards, JS -><- João Sebastião de Oliveira Bueno Calligaris ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Version 0.9.8 of Tiny-Fu is available, and feature/string freeze.
It ocurred to me that most GIMP translations are done by people working on the Gnome translation teams. These teams intensify their work (ok, at least pt_BR team), on the verge of stable gnome releases. Since GIMP packages are released in a different schedulle, I guess that this string freeze message should be forwarded to a global gnome-l10n mailing list, or many languages will only update tiny-fu when gnome 2.12 gets close. Regards, JS -><- On Sunday 27 March 2005 16:54, Kevin Cozens wrote: > Greetings, all. > > A tarball of version 0.9.8 of Tiny-Fu is now available at: > http://www.interlog.com/~kcozens/software/gimp/tiny-fu.html > > It was barely a week between the release of the 0.9.7 and 0.9.8 > versions. The main work for this new release was started before > 0.9.7 was made available. The 0.9.7 version provided a stable base > of code from which to work prior to the big changes that were about > to be introduced to the Scheme interpreter. > > This latest version includes one useful bug fix and one important > new feature. The bug fix allows Tiny-Fu to be used with GIMP in > batch mode. The important new feature is support for UTF-8 coded > strings. This allows the creation and use of scripts which need to > manipulate strings written in non-English languages. You can see an > example of what is now possible on the main web site for Tiny-Fu. > > It has been almost exactly one year since Tiny-Fu successfully run > its first script. The 0.9.8 version also marks another important > milestone in the life of this plug-in. This version is a release > candidate for a 1.0 version. As a result, the plug-in is now in > feature and string freeze. No new features will be added or strings > changed until after the release of a 1.0 version. > > The one set of changes I will accept are any updates to the > translation files which are very out-of-date with the exception of > en_CA, en_GB, and pt_BR. > > Prior to the release of 1.0, I will be running some additional > tests and would appreciate any reports of problems I may have > missed. I will also be starting to make the changes needed to allow > Tiny-Fu to be used with the current CVS versions of GIMP. Any > submissions related to new features will be held until after 1.0 is > released or will be incorporated in to the version for use with CVS > GIMP. > > > Changes since the 0.9.7 release: > > - Added UTF-8 support to the TinyScheme interpreter. > > - Changes to allow use of Tiny-Fu with batch mode. Fixes bug > #167964. > > ___ > Gimp-developer mailing list > Gimp-developer@lists.xcf.berkeley.edu > http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Colorizing Images and Video by Scribbling
On Tuesday 15 March 2005 18:03, Pepster wrote: > Their page says > "Our method is based on a simple premise: neighboring pixels in > space-time that have similar intensities should have similar > colors" > > I assume this to mean you need the "timing information of the > stroke", similar to data needed for recognizing handwriting. > > While I am not sure of the GTK low-level API for such a "capture", > a plugin using such low level functions would have to re-implement > the non trivial functionality of drawing the stroke (colors, brush, > what-have-you ...), which is pointless. > Nope. The "time" part of the "space time" proximity applies to animations (and movies, of course). For stativc drawings , it is all about spatial proximity. > I was asking if any of you see a better way to implement such a > method in the gimp. > > Hope I made myself clear this time. > > -Joseph > > Sven Neumann wrote: ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Free Guids
Hi, I was thinking... One of the great things of drawing with rulers and squares is the ability of drawing paralell lines at any angles. Currently, this cannot be easily be done with thew GIMP. Actually, even drawing a line at a given angle is rather difficult. And then one see those "GIMP_ORIENTATION_UNKNOWN" as a possible option for guides. What if these were implemented? Guides that could stand at any given angles, instead of just horizonatal and vertical? Please, I'd like to hear comments on the feature, not on implementation issues. Regards, JS -><- ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Adaptive Contrast Enhancement
On Wednesday 02 March 2005 09:30, Sven Neumann wrote: > Hi, > > [EMAIL PROTECTED] writes: > >Shlomi Fish and I independently ported the ACE plugin to GIMP > > 2.0/2.2. Now both codes are reunited again. I think it works very > > well now. Shlomi removed a lot of bugs I was not able to correct. > > It would be great if it could be added to GIMP-2.2 itself now. > > Anyone against this idea? > > No new features in a stable version, so there's no way this plug-in > is going to be added to GIMP 2.2. > I am pretty sure he meant adding it to CVS,a nd have it in the next stable release. > > Sven > ___ > Gimp-developer mailing list > Gimp-developer@lists.xcf.berkeley.edu > http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Re: optional scaling in the save dialog?
That is great. I did not know that the GIMP could reuse tiles from one image to another. Actually, I didi not tought this was done even from a layer to another - that explains why adding new layers to large images goes so smoothly. I am more than happy. How does this memory usega behave when one apply a transform (scale down in this case), ont he image, or on a copy of it? Because Mateusz wrote me that the disabling undo improved the performance of the operation. Maybe it is just the beneffits f not having "X" allocated anymore, and therefore no more swaps after the scale down. Regards, JS -><- On Sunday 20 February 2005 11:43, GSR - FR wrote: > I assume there is Copy On Write, thus delaying real memory usage > (and the bandwidth too) until the data changes. Lets see COW at > work: >(...) ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: optional scaling in the save dialog?
On Saturday 19 February 2005 16:06, GSR - FR wrote: > Hi, > > [EMAIL PROTECTED] (2005-02-18 at 2053.55 -0200): > > > > I am currently working on a poster, and it's huge (from the > > > > point of view of the amount of memory I have ;) ). Once in a > > > > while I have to post it to the mailing list for my people to > > > > see if they like it and tell me what to change. Every time I > > > > want to mail it I first have to save it (.xcf), then scale it > > > > down, save as jpg then undo the scaling or just close and > > > > load again. So I thought it would be great if there was an > > > > option in the save dialog to choose the size you want to save > > > > the image in. It could be hidden in the "Advanced Options" or > > > > something so that usually it wouldn't bother you. > > > > Try disabling script-fu previously to scale, > > then save as copy, and reload your image. > > I would go with duplicate image, scale the clone, save then close. > No undo problems that way, xcf version stays untouched, both disk > and memory. Let X bre a Huge Amount of Memory (tm) taken by said image, and Y be A Couple Kilobytes (tm) used by scaled down version Your proccess: - Initially using X memory duplicate image -> now using x * 2 memory. scale image down, with UNDO active -> using x * 2 + Y memory discard copy-> back to using X memory. My proccess: - Inittially using X memory - Disable Undo for this image - Scale down: Using Y memory. - Save copy - Revert: Using back X memory. As you see, they are roughly equivalent, exepct that your method, in the intermediate steps, use twice as much memory. The slowdown complained about is probably due to Tile swapping . Take your conclusions. > > GSR > > ___ > Gimp-developer mailing list > Gimp-developer@lists.xcf.berkeley.edu > http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] optional scaling in the save dialog?
On Friday 18 February 2005 19:31, Sven Neumann wrote: > Hi, > > Mateusz Misiorny <[EMAIL PROTECTED]> writes: > > I am currently working on a poster, and it's huge (from the point > > of view of the amount of memory I have ;) ). Once in a while I > > have to post it to the mailing list for my people to see if they > > like it and tell me what to change. Every time I want to mail it > > I first have to save it (.xcf), then scale it down, save as jpg > > then undo the scaling or just close and load again. So I thought > > it would be great if there was an option in the save dialog to > > choose the size you want to save the image in. It could be hidden > > in the "Advanced Options" or something so that usually it > > wouldn't bother you. > > What do you think about this? Should I put up a reuqest on > > bugzilla for that? It shouldn't be too hard to implement, since > > it's just one more operation during saving (like flattening or > > so) and it would require copying the Scale Image dialog somewhere > > to the Save Dialog. It would save you undo memory, and time. > Mateusz, I have two 1 liner script-fus to enable/disable undo . Maybe they can help you? Try disabling script-fu previously to scale, then save as copy, and reload your image. > No, this would only clutter the save dialog. It is already crowded > enough. If we'd do that, next week someone will call for > auto-whitebalance on save, adding a border and sending mail to > grandma. No way. > > > Sven > ___ ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] floating layers
On Wednesday 16 February 2005 14:05, Carol Spears wrote: > On Wed, Feb 16, 2005 at 11:10:55AM +0100, Sven Neumann wrote: > > > > There is no such thing as a floating layer, it's called a > > floating selection. Your argumentation is flawed. Of course if I > > paste something into a layer mask, I want to be able to position > > it. That's the whole point of a floating selection. This has, > > IMO, been discussed enough in Bugzilla. There is certainly room > > for improvement here and I am all for reducing floating > > selections as well as for making them easier to deal with. But we > > can certainly not get rid of them completely. That would be a > > major regression. > > what is the bug report. > bug 113477 > carol > ___ > Gimp-developer mailing list > Gimp-developer@lists.xcf.berkeley.edu > http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Some questions
On Sunday 13 February 2005 08:58, Jordi Canton wrote: > >You can embed ICC profiles in JPEG files. The lcms distribution > >contains code to insert and extract profiles: check the sources > > for jpegicc and friends. > > Thank you John, I have hust checked that code and compared it to > the actual GIMP jpeg part. As I can see, actually Gimp does not > support the embedding of ICC profiles in JPEG files. > > Is there any official mantainer of this part?. I can try to modify > this part myself and submit a patch, but I don't want to interfere > with anyone's work. Submit a properly commented patch to bugzilla - in bugzilla.gnome.org. That is teh way to go, and not interfering in anyone's work - regardless of anyone being more or less officially in charge of certain partts of the program. Once filed in bugzilla, your patch will be looked upon by teh core developers - revisons might get asked - and if it is approved, it will be commited by the developers themselves, ensuring no conflicts happen. And of course, you as anyone else, are mostly welcome to post usefull patches to bugzilla - It is not meant only for reporting problems, but also for feature requests and code management. Regards, JS -><- > > Jordi > ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Feedback on new rect select tool
On Sunday 13 February 2005 08:25, David Neary wrote: > Hi, Ok... Iá say I agree fully with Dave's comments. I'd have something to add here: > > One usability change which would be great, but I know that it is > a lot trickier, is to have the selection be both a selection and > adjustable at the same time. It would be great to be able to drag > the corners (or even, why not, the edges) of a selection to move > it around & resize it dynamically, but have it actually be a > selection if I do something like apply a filter. The question is > whether the adjustableness would only apply to the last element > added to the selection (ellipse, rectangle, or why not, > freehand?) or to the bounding box of the entire active selection. > I haven't thought a whole lot about it. > Great - I think that if the selection was not replaced by the rectangle, the adjustment could be - for the time being - on the boundng box of the selection. I say "for the time being" - because the olny satisfactory UI I can perceive for this is to have each element on the selection adjustable - that means that sucessive erctangle selects, ellipse, free hands, select by colors, use of quickmask, etc, should be individually "pickable" and re-edited. The only way this functionality might be implemented is if - or rather - when - Pippin's suggestions for what could be called an 'action' model for the drawables is implemented. That is - the GIMP would record not only the actuall raster data, but each action performed on a drawable as a "data independent" model. That would also allow for a great macro recorder, out of order undo/redo, per drawable undo/redo - and this - a fully readjustable selection. Maybe we could put some more thinking in how this proposed model would be achievable. > Cheers, > Dave. Regards, JS -><- ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Jury member sought for a Paris free software competition
On Monday 31 January 2005 09:03, David Neary wrote: > Hi all, > > I was contacted over the weekend by the organiser of a Paris > based free software contest, who wanted to know whether I knew > anyone in the GIMP project who was prepared to be a jury member > for the competition. What exactly is the contest about? Coding flor a new project? Fixing bugs on existing projects? Or just using some free software at all? Regards, JS -><- ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] xtns->extras ?
Hi, a few weeks ago I wrote mentioning that it might be a good idea to rename the "Xtns" menu entry to "Extras". Unless my ISP account ate selected e-mails from the list, that got no answer. On the optmistic side, I see that no one strongly disagrees with that. Therefore, I am trying it again: What do you say about renaming "Xtns" to "Extras"? I think it would be a good change to the GIMP's general "look and feel". Regards, JS -><- ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color Curves
Hi there! Please, feel welcome! The said news is that GIMP's color curve code is outdated and is begging for being rewritten, for about an year. :-( The good news, is that as you dive into it, you can also help the code in the GIMP itself. That said, the code is in app/base/curves.[ch], and tools/gimpcurvestool.[ch] Regards, JS -><- On Sunday 09 January 2005 06:13, Buck Arue wrote: > I really don't know where to begin. I am an avid Gimp user. I am > not a programmer or developer. This is my first attempt at > programming, so be gentle. > > In addition to image processing, I am also a bit of a videophile. I > am interested in porting the "Color Curve" function found in "The > Gimp" to "Avisynth" to be used for video. > > This is my first attempt at programming, so be gentle. I would > like to know where I might find the relevant source code for the > "Color Curve" function in "The Gimp"? > > Maybe I am biting off more than I can chew, but I would like to > attempt it, so any help or advice you could supply would be > appreciated. > > Thank You, > Buck Arue > > ___ > Gimp-developer mailing list > Gimp-developer@lists.xcf.berkeley.edu > http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Renaming the Xtns menu
Hi everyone! Due to a suggestion on the portuguese-br translation I had set up, I renamed, in GIMP 2.2 already, the "Xtns" menu option to "Extras". "Extras" is written and means the same in PT and EN, just as Xtns was being used as abreviation of "extensÃes". I am writting this because I liked the way it feels, with a whole word in there, instead of some pr3-h4x0r dialect, and am suggesting that it gets renamed in this development cycle. On other news, I was going to update my build today, as I've returned from holydays, and anoncvs seens to be down. :-( So I am with a pre-2.2.1 build right now. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Talkings about the road ahead.
Today the issue of the path to take to begin gegl- talks for the gimp arised again on #gimp. As irc is so transient, I was asked to save the talk in a more permanent way. Given there are just Q&A with ideas and nothing concrete, the list seems me to be permanent enough for this. Yuck - Just noted that I was without time stamps. It took place 12/22/2004, at about 17h00 UTC = pippin: So - I saw your mail listing the order in which you thought the tools should move to gegl pippin: Do you have any idea how that might happen (I mean, what gegl interfaces you use, how you make paintstrokes be ops, that kind of thing) A design sketch for gegl tools, I mean... bolsh: yes, but I have not had time to hack it into oxide/bauxite yet,. pippin: I'd be interested in reading your ideas, if you've written them down somewhere... I'm trying to get my head around what kind of interface gegl needs, and how much work needs doing to provide it bolsh: I have a lot of ideas,. and as well as hunches,. bolsh: I am starting to internally conceptualise how gimp image model fits with gegl,. and the place with least intrusion would be the tools,. new gegl based tools could even coexist with the current ones,. thus I think it would be the ideal proving ground,. (granted we wouldn't get high bitdepth whilst doing it,. since we'd still be using gimp drawables) <-- toady has quit (Leaving) --> toady ([EMAIL PROTECTED]) has joined #gimp bolsh: the compositing requires somewhat deeper restructuring to be really useful,. I think it is wise to start working to get the tools done,. before deciding on a design there,. the design I am using in oxide seems to work fairly well,. but I think it needs more review,. a sane form of a such review won't be possible until after some people have started building things with gegl pippin: What would you say about moving the brush and paint-tools compositing to Gegl first, so that brushes can have more parameters? bolsh: I am also,. kind of suggesting,. to allow blessing any image source with the 'drawable' properties,. this would mean that the source op gets a hidden internal chain of operations that are to be executed (the associated stroke history),. caching should eventually happend on the GEGL level,. but that kind of changes,. might have to wait until gimpdrawables are replaced by source ops from gegl,. joao: I don't quite follow pippin: how hard would it be to replace gimpdrawables by source ops? pippin: would this means we'll have to rewrite all the code that use GimpDrawable ? pippin: And what do you think about the plan that Daniel outlined some months back? It appears consistent with your idea pippin: IIRC, he was saying that we wouldn't need to migrate to the compositing model before we had started using GeglImage rather than (or contained in) GimpDrawable we were talking about this yesterday. Currently, a brush in gimp is a tempbuff - it can't do much by itself. We were talking about adding a UI for scaling, and implement rotation on the brushes. That could be done adding/bettering the transforms in tempbuff, or moving it to a gdkpixbuf, or using gegl to handle the brush. --> toyowheelin ([EMAIL PROTECTED]) has joined #gimp bolsh: starting with the tools,. and keeping the exiting infrastructure for support,. means earlier integration into gimp,. and the ability to start doing integration without breaking everything first,. pippin: Like I said, it sounds like your idea is consisitent with what Dan proposed - it's a step before everything else And it would mean depending on gegl, which is good pippin: the sooner we start the better. sooner == as soon as we branch http://www.mail-archive.com/gimp-developer%40lists.xcf.berkeley.edu/msg06446.html <- dans roadmap dindinx: It might be possible to wrap a GeglImage in a GimpDrawable and keep all the code there bolsh: this would be a wonderful first step, then But everything that uses data buffers directly (TimeManager, TempBuf) would need re-writing to use equivalent gegl structures bolsh: _might_ bolsh: it does dictate the future capabilities possible,. <-- toyowheelin has quit (Leaving) Which would ideally abstract away details like the tiles, and make the API simpler, perhaps even reducing code size pippin: Sure bolsh: aI see it,. mapping the whole internal data structure ofof gimp to a tree,. similar to what I have in oxide, woudl be a good thing s/aI/as/ pippin: That would mean, in short, replacing GimpImage by a graph, plus some auxilary stuff that doesn't have to do with data (like guides and undo) - does that sound right? bolsh: any thing touching a pixel doesn't belong above gegl bolsh: yes,. it means extending for instance my xcf2 draft with guides,. comments,. and other perasites that belong,. how it is modelled in a ui is a different aspect the other way of integrating it,. is reusing the exact same concepts used in gimp at the moment,. and
Re: [Gimp-developer] panel and winning splash
Hi Carol. [nothing of much interest on this mail for people who are ok with the panel] On Monday 13 December 2004 22:25, Carol Spears wrote: > On Mon, Dec 13, 2004 at 11:52:03PM +0100, David Neary wrote: > > Hi Carol, > > > > Carol Spears wrote: > > > "make a decision". was their any discussion here of the panel > > > needing the approval of these "artists"? the panel was put > > > together to make a recommendation to the developers. you need > > > additional handholding? was anyone interested in being on this > > > panel who can make a decision on their own? > > Can you please calm down? I am in the panel. The other four people in the panel are all part of the comunity formed by Gimp development in all ways it stays in touch - that is #gimp, bugzilla, and here at least. There were 672 splashes from which to pick one. You did run your script in there, and after some tens of seconds, it spilled out a movie, did not it? Each of us took time to appreciate each of the splashes over the last week. I can't speak for the others, but I looked at each of them in full size, in painfull proccess of narrowing down the list of viable splashes..Why painfull? Because most of the entries are, in their own way, very nice at least. The funny ones. The scary ones. So each one in the panel had to create a personal set of criteria to narrow the list, so that the whole panel had a small list upon which to debate. You express concern about the results of a panel. I think it is reasonable for you to perceive that the panel is concerned about this result as well. Otherwise, we'd just spill out the "highest ranking" among ourselves as the final winner. Instead, we decided that the choices we were left with were quite good, and that diffferent point of views would be apreciated. > >(...) > > If the panellists want to ask for the opinion of outside people, > > or give weight to mukund's page, so be it. When their decision is > > made, it will be final. > > a final recommendation. just spit it out. Carol, since it seems to be so easy, why do not yourself give the panel feedback. Which is your choosen one? (NB - this is mostly retorical at this point, as we have a good winner candidate by now - nonetheless I'd like to know your one pick among those 600+ entries) > > ask adam. adam is an artist and has been involved with gimp since > before you, me, tigert and jimmac -- i dunno about drc. Adam is in the panel. > if they did not want to work as a group, for what reason was it > formed? We want and are working as group. A nice group of persons from different countries with different entries which got a unique chance to learn about each other's inner feelings about art and feelings about The GIMP and its usages as well. I may be speaking for myself, but it is a lifetime experience. > > if they were afraid of peoples opinion of their opinion, why did > they want to be on the panel. How would us know that people would arise questioning the panel before? On a side note, I feel the panel had been set by the Release Manager, and fear no one outside. As far as I am concerned, if the panel would vote for the dullest splash out there, that would be the panel recomendation and no more questions. But how do you feel about questioning any judge about being afraid of other's opinions when you yourself are attacking the panel - and at least on this list, you are the only one doing so. > > this is crap. this is pathetic like this stupid election we just > had here in the states. Ok - I am writting this lenghty reply, because _this_ I found offensive. I agree that a way to select a winner should have been determined before opening up for the contest for the entries. But it was not done. Since the formation of the panel itself was a sugestion on this list, and people got a chance to propose a better, working idea, I am perfectly confortable with the panel. Just because if determined beforehand, it probably would have been the better idea anyway. > is the recommendation from this panel to be have tigert "i approve > this" to make it worth something? > We feel more confident now we've read Tigert's comments on some of our picks, if that maters. > is there anyone on the panel whose opinion does not count? No. It is a five way panel, and everyone is doing their part and getting listened. > > carol Regards, JS -><- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] A beginning GIMP Developer?
Hi and welcome! There are people in better position to answer you on this! But I am just quite happy to see a mail like this - I myself just go around proposing weird features, and eventually finding and fixing a minor bug. Lots of fun, either way. So...bugzilla is the way to deliver bug corrections. You should better be using GIMP from CVS, read the 'Hacking' file in there for building tips - if you aren't already. Them, just check the bugs in bugzilla, erradicate them, taking care to maintain the coding style (it is GNU style, I've read somewhere). After it works, make a patch by running diff with "-u3" option, and attach that patch to the bug report. Now, keep online to hear from Sven, Bolsh, Alan, Carol and others... Oh, also, underliying GTK and the GIMP object system is Glib and Gobject - you should learn about these. There is a small app called "devhelp" which allows for interactive browsing of the API. Regards, js -><- On Sunday 12 December 2004 19:52, Henry Roeland wrote: > He all GIMP developers out there, > > I'm new to this list and therefore lets introduce myself first. As > a Software developer I'm working for about 2 years now with > Java/C/C++ and other languages like XML/XSLT. My expirence with > C/C++ is about medium and I know a little about Linux/UNIX > programming but have more expirence with Win32 platforms.My > expirence with GTK+ and GIMP code is zero. > > At this time I'm working(Using) now about 2 weeks with The GIMP for > graphical stuff (as a hoby) and I'm very excited about all that > GIMP offers! Because I'm a developer I like to help fixing bugs or > add some new features. A already debuged some of the code but > because of my lack of expirence with GTK+ and all I like to begin > easy :-). > > In short: Can I help with bug fixing? If so should I start with bug > fixing (which bugs) and how and to who can I deliver the patches? > > Greetings, > > Henry Roeland ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Scissors tool
On Thursday 09 December 2004 06:45, Laxminarayan Kamath wrote: > OOps, Sorry Sven, Gmail is nice but is confusing for replies. Will > be care full next time. > By the way, what i mean is, when such confusions occur, like > whether or not to remove a tool from the toolbar, isn't it nice to > have a poll engine and make the poll public? You are worrying over the edge here. There is no chance this tool will be removed - not this time, nor soon. What happened is that I, having the opinion that the tool is borken, sent a question about it to the list - which is public, in some sense. People replied that not only it is actually usable, but they use it on an often basis. Therefore, there is no sense in hiding it. And just one more point: I never suggested the removal of the tool, but just hiding the tool - it would be available from dialogs->tools, even to be put back into the toolbox. If a change is made to the GIMP that you do not like - in a way it brakes the way you work, Bugzilla is the place to ask for the old behavior back. Recently, for example, there was a bug asking for the old behavior of the Move tool - that would change the selected layer. That was promptly implemented as an option. Regards. JS -><- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Scissors tool
On Wednesday 08 December 2004 04:17, Austin Donnelly wrote: > > I think I was probably the last person to do any major work on the > scissors tool, and that was in 1999 to port it to the (then new) > tile-based world. > > The code when I took it on was a "software Vietnam"; a complete > mess. I had to read the SIGGRAPH paper it was attempting to > implement before I could fix it, and believe me it left my hands > much cleaner than I got it! > > There are two areas where it could do with improvement: > - it doesn't handle tile-boundaries (it treats them as edges) hmm..this explains the major complaint I had about it. Sorry again to all who make use of the tool. > - the point editing interface sucks; I merely made the existing > one work but it might be interesting to see if it could use the > same code from the Path tool (that was always the plan) It may not be fine, but it works. As stated in other e-mail, it could benefit from undo. The tile boundary == edge thing is not good. > Austin > > Regards, Joao ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
