[Gimp-developer] GIMP 2.2 and Script-Fu/Tiny-Fu.
Greetings, all. In a previous message written by Sven about preparing for GIMP 2.2, he wrote the following: Script-Fu vs. Tiny-Fu We should come to a conclusion whether and how Tiny-Fu can replace Script-Fu. I'd suggest we make separate packages gimp-script-fu and gimp-tiny-fu and remove Script-Fu from the gimp tree. This issue needs to be discussed now that Sven is trying to get the plans for GIMP 2.2 nailed down. There are several issues here. Should Script-Fu be made a separate package outside of the main GIMP source tree? If not, is it time to replace Script-Fu with Tiny-Fu in the source tree? Should Tiny-Fu just be made a separate plug-in ready to be added to a GIMP install as/when scripting is needed? In regards to Script-Fu vs. Tiny-Fu, I have had little feedback about the Tiny-Fu plug-in. I can think of one issue (getting a "No memory!" message when too many scripts are installed) that needs to be addressed for a GIMP 2.2 release. Other than this one point, I think Tiny-Fu is in a state where it could replace Script-Fu. If it is felt Tiny-Fu isn't (or won't) be ready for 2.2 but would be soon after, the best approach may be to make Script-Fu a separate plug-in allowing Tiny-Fu to be dropped in later on (either as a separate plug-in or as part of the main GIMP package). Replacing Script-Fu with Tiny-Fu could help push Tiny-Fu along a bit (ie. with translations) if it isn't fully ready yet by exposing it to more users but what is in the best interest of GIMP and its users? -- Cheers! Kevin. (http://www.interlog.com/~kcozens/) Owner of Elecraft K2 #2172|"What are we going to do today, Borg?" E-mail:kcozens at interlog dot com|"Same thing we always do, Pinkutus: Packet:[EMAIL PROTECTED]| Try to assimilate the world!" #include| -Pinkutus & the Borg ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Bugzilla user-watching
Hi all, There has been a change in policy in bugzilla since the upgrade which makes handling bugs much easier, but isn't yet widely known. For anyone who wants to follow bugzilla, but who isn't on the [EMAIL PROTECTED] alias, there is a new method to get at that information. An added benefit is that you don't get any spam sent to [EMAIL PROTECTED] too, and an administrator doesn't have to add you to a text file somewhere. Simply go to your user preferences in bugzilla, and add [EMAIL PROTECTED] to the list of users you are watching. Check all the boxes so that you get a notification mail when the user is added as a CC, assigned a bug, reports a bug, comments on a bug or receives a mail from a bug someone else commented on. You can also reduce the volume of mail by removing some of those. The new procedure for product aliases in Bugzilla is similar - create a new bugzilla user (Bugzilla maintainers can do this without there actually being a mail account at the other end) with an address ending in @bugzilla.gnome.org (example: [EMAIL PROTECTED] or [EMAIL PROTECTED]), set that user to be automatically assigned bugs for the relevant modules, and get everyone interested in the module to watch the user. I think this is great, since it removes one layer of administration from the loop for people who want to follow a product. In fact, I'm like to reccommend removing everyone from [EMAIL PROTECTED], and using watching instead for GIMP bugs. What do people think? Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Colour management - who can do what?
Hi Robert, Robert L Krawitz wrote: Firstly, I've been quiet on this subject for a few weeks because I've bought a new printer, and my limited coding time has been spent tweaking gimp-print to settle one or two minor print quality issues! Which we've very much appreciated, even though I still have to try out your latest. I've been busy with other things, like making dcraw do the right (IMHO) thing. But I digress. Don't worry, I wasn't feeling unappreciated - just torn between two projects, like yourself :) It would *really* be helpful to plug this into the Print plugin, if not Gimp-Print itself, so that when the GIMP feeds 8 bit values to the plugin these values are reprocessed into 16 bit values, rather than 8 bit ones. This should be a fairly trivial change once we have the infrastructure to get the current working profile and/or the image's profile into plugins in general. The print plugin would itself need to link against lcms, and it would simply fetch the current working profile (or the image's own profile if there is one), and create a transform from 8-bit data in the source profile to 16-bit data in the destination profile. The sticking point would be the destination profile - the user would need one that accurately describes gimp-print's characteristics! We could of course just use sRGB (which lcms has built-in) as a default. All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Colour management - who can do what?
Hi Alastair, thanks for replying and collecting this list of TODO items. I will try to take care of implementing the features that we need in the core and in the module API. I just need to sit down with Mitch and discuss some remaining questions about the module API. I hope to have the needed infrastructure implemented by the end of next week. I will keep you informed and will ask for your advice when I run into problems. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Creating a painting program using the GIMP or its widgets
Hello folks. I have this idea to create a specialized painting program, something that would allow you to paint (with a tablet), while getting as little as possible in the way of the actual painting. Currently I am investigating different possibilities and approaches, and I would really appreciate some input here. If you would be so kind to bear with me, I'll provide some background. Please forgive the lengthiness. =) I am a student at a game developers school in Sweden, and one of the things we do for fun is to "compete" in speed painting with weekly themes - lots of people draw a lot more than that, but I'm no gfx artist, just in it for the fun. Anyway, some people use Photoshop, some use more specialized programs like OpenCanvas in different versions and so on. General feeling is that there is some fundamental flaw with most of these programs when it comes to doing paintings. Photoshop, for instance can do anything you need, but the interface is really backwards for the job. OC on the other hand, may lack functionality or just have some stuff that should be changed. When discussing stuff like that back and forth, we came up with a few ideas on how a drawing program should behave, and I started thinking that it might be possible to actually write one - and open source would be even better, anyone could at least theoretically get the app they wanted. Before anything else, I started looking around for GUI toolkits and the like that could be used for this - the musts that such a toolkit should have were: * Tablet support - the program would be really tablet centered, so we want to leverage what a tablet can do. This includes tilt, using the eraser and so on. * Windows support - most people I know use it and won't switch no matter what, however I would like Linux support since that is what I use at home. If other platforms like Mac are easy to add, so much better. * Enough basic image manipulation and viewing for it to be not too hard to implement different brushes that are more than just adding pixels to a bitmap. This should be for artists, not a MS Paint clone. ;-) * Open source - is not an actual must, but a strong preference, and probably the only viable way anyways. Looking around some, what I found that seemed to fit all these things (although I haven't actually tried tablet support, not on any platform) would be GTK+. I read up a bit on the docs, and it seemed that such a thing could be done in it, but would require quite some effort (might be mistaken). I went further and had a look at GIMP, which I use now and then, but I rarely do image manipulation, so I'm not that familiar with it. Anyhow, playing around with GIMP the application, most or all things that is needed (and much, much more) already is there, but the interface is not at all suited for this job. Don't get me wrong, for image processing it probably is very fitting, but for drawing, you ideally want to have the tablet under one hand and the other hand on the keyboard, with everything common possible to do without moving either. This is actually one of the goals I have, once the basic colors are on the canvas, you should not need any other window, not even the color selector, and all commands accessible under the left (or right) half of the keyboard together with the tablet. See later for examples. Anyhow, the GIMP as it is is not suitable for this task, you don't want to right-click-context everything, you just want to draw. ;-) I also downloaded the source, read through most of the devel-docs and looked around a little - but I find the project is really big and hard to grasp. Add to that that I'm not all that good at C, although I can usually modify other peoples code. ;-) I prefer to code in scripting languages, but I'm not afraid to get my hands dirty if that is the best approach and I can get some help. Anyhow, now we are closing in on my actual questions; it is pretty hard to formulate them, because first and foremost I actually need advice on the best approach for something like this, if it is viable at all. I can think of several ways to go: * Writing an application from scratch, using GTK+ and GIMP widgets/functions/etc. Question here is if that is possible, at least easily enough. Can the GIMP libraries be used like that? * Modifying the GIMPs interface somehow: - By actually forking, tearing apart and rearranging - not a tempting idea for many reasons - By creating a parallell main and building it up that way, using only the parts needed - By modifying the UI somehow, via plugins or the like - is that possible? The absolute ideal on many levels would actually be a plugin that allowed you to switch interface while retaining the whole GIMP. This I like the most, because it doesn't hurt to have all the extra functions for image manip, they should just get out of the way while doing the painting. Especially if it could be accomplished via some kind of scripting, so there would be no need for compiling on several platfor
Re: [Gimp-developer] Creating a painting program using the GIMP or its widgets
Hi, Kristoffer Lundén <[EMAIL PROTECTED]> writes: > Anyhow, playing around with GIMP the application, most or all things > that is needed (and much, much more) already is there, but the > interface is not at all suited for this job. Don't get me wrong, for > image processing it probably is very fitting, but for drawing, you > ideally want to have the tablet under one hand and the other hand on > the keyboard, with everything common possible to do without moving > either. This is actually one of the goals I have, once the basic > colors are on the canvas, you should not need any other window, not > even the color selector, and all commands accessible under the left > (or right) half of the keyboard together with the tablet. See later > for examples. Anyhow, the GIMP as it is is not suitable for this task, > you don't want to right-click-context everything, you just want to > draw. ;-) I don't think you need a new program or do a lot of hacking. All you need is to configure some more keyboard shortcuts than what GIMP comes with preconfigured. Then press F11 for fullscreen mode and start drawing. I suggest you use the 2.1 development version since it allows to bind a lot more functions to keyboard shortcuts (or other input devices). I think all of the functions you listed are already available. If there is stuff missing that you need, tell us about it. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP 2.2 and Script-Fu/Tiny-Fu.
> Replacing Script-Fu with Tiny-Fu could help push Tiny-Fu along a bit > (ie. with translations) if it isn't fully ready yet by exposing it to > more users but what is in the best interest of GIMP and its users? I know I'd much prefer another stable release with Script-Fu in it first, but that is my entirely subjective opinion. I fear having to rewrite some of my scripts having already written gimp 1.2 and gimp 2.0 versions. Compatibility is important to me, even if only small changes are necessary it causes problems. I dont relish the prospect of new scripts I write not being usable by people who still have gimp 2.0.x or even 1.2, users are still requesting backports of scripts to 1.2. It may seem like Gimp 2 has been available for ages, particularly for those who have been using gimp 1.3 but Gimp 2.0 was only released this summer. That said I'll certainly hope to instal Tiny-Fu alongside Script-Fu and sort things out after 2.2. - Alan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Colour management - who can do what?
Date: Tue, 07 Sep 2004 19:34:41 +0100 From: "Alastair M. Robinson" <[EMAIL PROTECTED]> > It would *really* be helpful to plug this into the Print plugin, if > not Gimp-Print itself, so that when the GIMP feeds 8 bit values to the > plugin these values are reprocessed into 16 bit values, rather than 8 > bit ones. This should be a fairly trivial change once we have the infrastructure to get the current working profile and/or the image's profile into plugins in general. The print plugin would itself need to link against lcms, and it would simply fetch the current working profile (or the image's own profile if there is one), and create a transform from 8-bit data in the source profile to 16-bit data in the destination profile. The sticking point would be the destination profile - the user would need one that accurately describes gimp-print's characteristics! We could of course just use sRGB (which lcms has built-in) as a default. I'd really like to figure out the right thing for Gimp-Print to do here, and then apply the profile inside Gimp-Print. -- Robert Krawitz <[EMAIL PROTECTED]> Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP 2.2 and Script-Fu/Tiny-Fu.
On Tue, 7 Sep 2004, Alan Horkan wrote: > > > Replacing Script-Fu with Tiny-Fu could help push Tiny-Fu along a bit > > (ie. with translations) if it isn't fully ready yet by exposing it to > > more users but what is in the best interest of GIMP and its users? > > I know I'd much prefer another stable release with Script-Fu in it first, > but that is my entirely subjective opinion. > > I fear having to rewrite some of my scripts having already written gimp > 1.2 and gimp 2.0 versions. Compatibility is important to me, even if only > small changes are necessary it causes problems. I dont relish the > prospect of new scripts I write not being usable by people who still have > gimp 2.0.x or even 1.2, users are still requesting backports of scripts to > 1.2. It may seem like Gimp 2 has been available for ages, particularly > for those who have been using gimp 1.3 but Gimp 2.0 was only released this > summer. > > That said I'll certainly hope to instal Tiny-Fu alongside Script-Fu and > sort things out after 2.2. > Given that 2.2 is supposed to be api-compatible with 2.0, I think that should extend to the scheme extension as well. Also, I'll again repeat my objection to the idea that the scheme extension be packaged separately from GIMP. We have always had Script-Fu as a universal -- the one scripting system you could count on for all gimp installations on every platform. It would be quite a shame if that was no longer the case. Nathan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
