Re: [Gimp-developer] Misnamed structure element in SFScript structure?
Hi, Simon Budig [EMAIL PROTECTED] Include a GUILE in the Gimp sourcecode, make sure that it doesn't conflict with other GUILEs on the target system and use it as the GIMPs default language. Perfectly fine with me as long as I have a language that is guaranteed to be available for 99% of the GIMP installations. I don't think we should do that simply because I don't see what is so important about having a self-contained scripting language. I'd rather like to see three or four well-maintained and working scripting languages that can be installed separately. If we can make sure that the language extensions work and can be easily installed that should be good enough then. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Misnamed structure element in SFScript structure?
Hi, Sven Neumann wrote: Simon Budig [EMAIL PROTECTED] Include a GUILE in the Gimp sourcecode, make sure that it doesn't conflict with other GUILEs on the target system and use it as the GIMPs default language. Perfectly fine with me as long as I have a language that is guaranteed to be available for 99% of the GIMP installations. I don't think we should do that simply because I don't see what is so important about having a self-contained scripting language. I'd rather like to see three or four well-maintained and working scripting languages that can be installed separately. If we can make sure that the language extensions work and can be easily installed that should be good enough then. I'm with Simon - at least one scripting language installation's a good idea. We might assume that perl or python are more or less universally available, but we can certainly not assume that guile is always installed. Given the fact that script-fu has historically been the reference language binding (and it continues to be), we should go out of our way to make sure it's available, IMHO. Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Updated roadmap (so people don't laugh at the old one)
Hi, David Neary [EMAIL PROTECTED] writes: This roadmap should not be seen as set in stone, but I agree with Freedman Dyson that it is better to be precise and wrong than to be vague. If we set ourselves vague targets, then we will arrive at them a long time after we'd like. So what? So, without further ado, here's the updated roadmap... are there any comments? I'd like to note that I personally very much dislike the fact that you published these fixed dates. They haven't been discussed as such and I don't think it is helpful to set such dates at all. I do believe that it is important to publish dates for feature and API freezes since developers need to know about them and the earlier they know the better. But it is IMO a very bad thing to publish release dates. It would have been OK to say that we target a 2.0 release this month and that 2.2 is supposed to be out in summer, perhaps even in June. However publishing a fixed date for each and every release that we will possibly do during the next months is IMO the worst thing we could have done. Let alone the fact that release dates for 2.0.1 or even 2.0.2 are completely unreasonable since they depend on facts we cannot know yet. I would like to let people know that I will not respect any of these dates. The GIMP project is already putting up enough pressure without people trying to nail us down on release dates. Things would be different if someone payed a handful of GIMP developers. They could be responsible for the milestones then and I could understand why someone would want to see such a list. However as long as GIMP is a project that is driven by voluntary contributions, we should IMO avoid to publish such lists. If the GIMP developers decide that such list of published milestones is required for the future development, then I am going to look for other projects to contribute to. After all this is supposed to be fun. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Misnamed structure element in SFScript structure?
Hi, Dave Neary [EMAIL PROTECTED] writes: I'm with Simon - at least one scripting language installation's a good idea. We might assume that perl or python are more or less universally available, but we can certainly not assume that guile is always installed. Given the fact that script-fu has historically been the reference language binding (and it continues to be), we should go out of our way to make sure it's available, IMHO. It's just a packaging issue. As long as we make sure that everyone can install gimp-script-fu, we have script-fu support. Do you really want to continue to include it with GIMP with all the problems that arise from doing that? I don't think it's worth it. In the long run we should move as much as possible out of the GIMP package. This will assure that we provide a stable and powerful API and will enable more extensions and plug-ins to be written. IMO moving script-fu out of the tree and putting it on the same level as gimp-perl and other language bindings is a very important thing to do. The sooner it happens the better. Actually I was considering this for 2.2 (along with gimp-python). We are not doing ourselves a favor if we treat Script-Fu any better than other language bindings. Especially since it is technically the worst of them all. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Updated roadmap
Hi, Sven Neumann wrote: David Neary [EMAIL PROTECTED] writes: This roadmap should not be seen as set in stone, but I agree with Freedman Dyson that it is better to be precise and wrong than to be vague. If we set ourselves vague targets, then we will arrive at them a long time after we'd like. So what? So what??? You're serious? I'd like to note that I personally very much dislike the fact that you published these fixed dates. They haven't been discussed as such and I don't think it is helpful to set such dates at all. I'm not pinning you down to anything - this roadmap was the result of the discussion we had yesterday on IRC, where you wanted a 2.2 release in 4 months - well, here's what that means in terms of releases with a 2 week release cycle. I do believe that it is important to publish dates for feature and API freezes since developers need to know about them and the earlier they know the better. If we're moving to a time-based release schedule (which I think we should) we also need to respect those dates. However publishing a fixed date for each and every release that we will possibly do during the next months is IMO the worst thing we could have done. OK - I could have been more vague and said 2.0 in February, branch in March, feature freeze the end of April, and left it at that. I think it's interesting to see what that means - it means that (assuming everyone is going to keep working on fixing bugs after 2.0 comes out), we have a 6 week development cycle for 2.2.0. That means 3 releases before the feature freeze, going on the current release rate. I for one think that's interesting... putting dates on it is merely a way of making something concrete rather than having vague nebulous type stuff. Let alone the fact that release dates for 2.0.1 or even 2.0.2 are completely unreasonable since they depend on facts we cannot know yet. I disagree... the idea should be that everyone works on stabilising 2.0 after it comes out (there's already a 2.0.1 milestone in Bugzilla which has a fair few bugs on it, and will soon have more), and then that everyone switches to the HEAD after a 2.0 branch. We can't just forget about 2.0, though, and we should try to get a stable release out before we start 2.2 pre-releases, IMHO. So we *can* plan 2.0.x releases - whatever bug-fixes are in CVS at that stage get released. It's that simple. I would like to let people know that I will not respect any of these dates. That's your choice... and since you do the builds for the releases, you have the power to impose your will on the project. I hope that you will at least respect the important points of this - that is, that we try to do a release every few weeks, and that we are careful about what we put in the HEAD once we branch off a 2.0 branch. Like I said, the release dates are not a rope to hang ourselves with - they're a guideline about when it's a reasonable time to have a release. But you're free to do whatever you like with them, including ignoring them completely. The GIMP project is already putting up enough pressure without people trying to nail us down on release dates. No-one's given us a huge amount of slack over the first pre-release being 3 months after we said in August, or the feature freeze being 2 months later than we said it would be, or that 2.0 is going to be over 2 months late related to what we thought during the Summer... why do you suddenly think we're going to get a lot of crap now? The project is getting pressure from people because we don't release often, which is the whole point of the release roadmap. Perhaps it's too precise - you had the same disagreement over the last one - I for one think it's useful. Things would be different if someone payed a handful of GIMP developers. They could be responsible for the milestones then and I could understand why someone would want to see such a list. However as long as GIMP is a project that is driven by voluntary contributions, we should IMO avoid to publish such lists. I think that the fact that we're a voluntary project is a good reason to have a list. In fact, I think that having some kind of a list is independant of the type of project. If the GIMP developers decide that such list of published milestones is required for the future development, then I am going to look for other projects to contribute to. After all this is supposed to be fun. How much fun is it when you're spending 3 years between releases? If we say it'll be done in 4 months, and leave it at that, we'll still be talking about stuff that absolutely needs doing a year from now, and we won't have a release for a few more months after that... what's wrong with saying what we want to do before we do it? Releasing is fun, seeing people use the software you put time into is fun, 3 year release cycles are not. And of course milestones aren't required, that's just ridiculous. But they can be useful. That's all... don't read more into this
Re: [Gimp-developer] Updated roadmap
Hi Dave, Dave Neary [EMAIL PROTECTED] writes: This roadmap should not be seen as set in stone, but I agree with Freedman Dyson that it is better to be precise and wrong than to be vague. If we set ourselves vague targets, then we will arrive at them a long time after we'd like. So what? So what??? You're serious? Yes, absolutely serious. Nothing is bad about a release that is delayed because the software isn't ready for general consumption. The reasons for this may be unforeseeable. It could be private trouble a developer is having, high workload at the job, bugs that are discovered late. Of course it would have been nice to release in time but if it doesn't happen, so what? That's your choice... and since you do the builds for the releases, you have the power to impose your will on the project. I hope that you will at least respect the important points of this - that is, that we try to do a release every few weeks, and that we are careful about what we put in the HEAD once we branch off a 2.0 branch. We have always done that; it's not really worth mentioning it. No-one's given us a huge amount of slack over the first pre-release being 3 months after we said in August, or the feature freeze being 2 months later than we said it would be, or that 2.0 is going to be over 2 months late related to what we thought during the Summer... why do you suddenly think we're going to get a lot of crap now? Because so far noone was stupid enough to say things like 2.0.0 on February, 25th. Being vague certainly is better than setting such arbitrary dates. I think that the fact that we're a voluntary project is a good reason to have a list. In fact, I think that having some kind of a list is independant of the type of project. I am not questioning some kind of list. But I don't want to let your list stand uncommented. It contains arbitrary dates that have never been discussed. How can it be useful to setup such a list if we haven't even agreed on things like what exactly do we want to do in GIMP 2.2? You should be aware this these dates will be cited on various occasions without being put into the right context. How much fun is it when you're spending 3 years between releases? If we say it'll be done in 4 months, and leave it at that, we'll still be talking about stuff that absolutely needs doing a year from now, and we won't have a release for a few more months after that... what's wrong with saying what we want to do before we do it? Releasing is fun, seeing people use the software you put time into is fun, 3 year release cycles are not. It's unreasonable and unfair to argue like this since everyone agreed on a shorter release cycle already. This is not the point in question here. And of course milestones aren't required, that's just ridiculous. But they can be useful. That's all... As I said, setting a date for a freeze is required; setting dates for releases will IMHO do nothing but harm. I know GNOME users have more fun - they get all the cool stuff within 4 months of it going into CVS. You are not observing the GNOME development very closely then. Do to the fixed release dates, a lot of good stuff is left out of the official releases and delayed for another 6 months even though it was almost ready. However, it doesn't make too much sense to compare with GNOME since GNOME releases are a collection of packages. They need these rules in order to coordinate all the different software projects that are contained in such a release. I don't think you can draw the conclusion that such release policies would do good for The GIMP. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Misnamed structure element in SFScript structure?
Dave Neary ([EMAIL PROTECTED]) wrote: We might assume that perl or python are more or less universally available, [...] Please note that this definitely is wrong. We have a Windows user base and they most probably don't have Perl or Python installed. Otherwise I wouldn't bring this topic up. Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Misnamed structure element in SFScript structure?
Hello, Sven Neumann wrote: It's just a packaging issue. As long as we make sure that everyone can install gimp-script-fu, we have script-fu support. Do you really want to continue to include it with GIMP with all the problems that arise from doing that? I don't think it's worth it. Including guile doesn't mean supporting it. As it is, there are a bunch of things we include that don't get much support because the original authors have gone their own way. This time we're not even talking about *pretending* that this is a GIMP thing - we set up a configure script that checks if there's a local guile installed, if there is it uses it, otherwise it calls configure make on its copy, and uses it in the GIMP. It is the same thing as we currently have, except that instead of George Carrette's SIOD, we'll be using GUILE. And this time, we will be using an official release of a scheme interpreter, not a GIMP modified copy. I don't see a downside. In the long run we should move as much as possible out of the GIMP package. This will assure that we provide a stable and powerful API and will enable more extensions and plug-ins to be written. IMO moving script-fu out of the tree and putting it on the same level as gimp-perl and other language bindings is a very important thing to do. There is a certain point at which this is unreasonable. If we move all the C plug-ins out into another module, and all the brushes, patterns and other data to another module, and all the script-fu and python-fu to separate modules, we'd have a small, stripped down core, but a usable GIMP would be made up of 6 or 7 CVS modules, 6 or 7 packages to download, and 6 or 7 packages to maintain. The sooner it happens the better. Actually I was considering this for 2.2 (along with gimp-python). We are not doing ourselves a favor if we treat Script-Fu any better than other language bindings. Especially since it is technically the worst of them all. I'm afraid that moving all of the langauge bindings out of the core would only result in the bindings not being maintained as well. As it is, the Python bindings are in need of a bit of a work-over before 2.0, if I remember correctly, and script-fu itself is only getting the minimum of maintenance for it not to be broken. Anyway - working towards a minimalist GIMP is kind of going away from what I'd like to see. I'd be more interested in being pretty liberal about the patches and plug-ins we accept in the core, and get more plug-in authors involved in maintenance work and development. For that we need to define guidelines for getting a plug-in into the core, and get the word out that we're interested in more or less anything and everything to do with image processing. Hand in hand with that we would also need guidelines for when a plug-in would get dropped (temporarily?) from the distribution if it is unmaintained. If we have decent guidelines, this would add very little work for maintainers, who could just let plug-in authors take care of their own code. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Misnamed structure element in SFScript structure?
Ooops, that should have been gone to the ML as well... Sven Neumann ([EMAIL PROTECTED]) wrote: Simon Budig [EMAIL PROTECTED] Include a GUILE in the Gimp sourcecode, make sure that it doesn't conflict with other GUILEs on the target system and use it as the GIMPs default language. Perfectly fine with me as long as I have a language that is guaranteed to be available for 99% of the GIMP installations. I don't think we should do that simply because I don't see what is so important about having a self-contained scripting language. I'd rather like to see three or four well-maintained and working scripting languages that can be installed separately. It is pretty easy to see why a default scripting language is important, and I guess it is your grumpiness against script-fu that prevents you from seeing it. When somebody on IRC has a problem that is cumbersome in the UI, but can be solved with three or four PDB calls (e.g. Flip Layer menu entry) I'd hate to tell him that he has to install a monster like Perl/Python or whatever, to be able to use my quickly hacked three line solution. And even if he has Perl installed, I could not provide a script for him, because I only know about Python and Script-Fu. I don't want to be a master in all bindings available for gimp, just to be able to provide such a thing. I want to focus on one or two languages. This has happened in the past and Script Fu was a nice solution for stuff like that. And that is the reason why it is important to have a simple language available always. Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Misnamed structure element in SFScript structure?
On Thu, Feb 05, 2004 at 01:06:58PM +0100, Sven Neumann [EMAIL PROTECTED] wrote: I don't think we should do that simply because I don't see what is so important about having a self-contained scripting language. I'd rather like to see three or four well-maintained and working scripting languages that can be installed separately. If we can make sure that the language extensions work and can be easily installed that should be good enough then. I think this is already reality, as most people will get gimp from a gnu/linux distribution and many if not most of them will ship these extensions as seperate packages already. (and the rest should easily be prepared to deal with installing things from source). To me it's all a matter of the installer. Simons agruments, however, smell a lot of standard gimp extension language, because his goal is to have one language that is always pat of gimp, which would effectively be a standard. I don't think that's a bad idea at all, especially when we later think of macro recording and other tasks, where we _will_ need some standardized macro language that should be easy to translate into real scripts. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Updated roadmap (so people don't laugh at the old one)
Hi, On Thu, 2004-02-05 at 13:27, Sven Neumann wrote: David Neary [EMAIL PROTECTED] writes: [snip] So, without further ado, here's the updated roadmap... are there any comments? [snip] The GIMP project is already putting up enough pressure without people trying to nail us down on release dates. Things would be different if someone payed a handful of GIMP developers. They could be responsible for the milestones then and I could understand why someone would want to see such a list. However as long as GIMP is a project that is driven by voluntary contributions, we should IMO avoid to publish such lists. If the GIMP developers decide that such list of published milestones is required for the future development, then I am going to look for other projects to contribute to. After all this is supposed to be fun. I couldn't have said it any better myself, Sven. The GIMP is a spare time project for all of us - personally I have enough deadlines and stressful release dates as part of my study. I don't need more of these during my free time. The GIMP is being developed by a group of volunteers - Personally I'm in it partly because it's lots of fun and partly because I learn a lot during the the process. Imposing a fixed release schedule will take a great deal of fun out of the project, I'm afraid. Don't get me wrong. I believe having a road map is a good thing. As with any major software project we too need to plan ahead. But I am convinced we should stick to only hinting at release dates like we did at the last GIMPCon. The main goal of the road map, IMO, should be documenting which major changes goes into which release - and even then this road map should not be set in stone. It's no secret that the GIMP project is rather short on active developers these days (I haven't been very active myself lately either) - and I think setting a tight release plan/road map will only discourage new developers to start spending what little spare time they may have contributing to The GIMP. Sincerely, ./Brix -- Henrik Brix Andersen [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Misnamed structure element in SFScript structure?
[EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) wrote: On Thu, Feb 05, 2004 at 01:06:58PM +0100, Sven Neumann [EMAIL PROTECTED] wrote: I don't think we should do that simply because I don't see what is so important about having a self-contained scripting language. I'd rather like to see three or four well-maintained and working scripting languages that can be installed separately. If we can make sure that the language extensions work and can be easily installed that should be good enough then. I think this is already reality, as most people will get gimp from a gnu/linux distribution and many if not most of them will ship these extensions as seperate packages already. Actually, most GIMP users probably get their GIMP from Jernej - OK - the GNU/Linux side of things gives us a nice big install base on Linux, but proportionately very few Linux people actually *use* the GIMP. I'd guess that the majority of our power users are on Win32. (and the rest should easily be prepared to deal with installing things from source). This is the big developer fallacy... installing from source is not easy, particularly if you have a desktop set-up and not a developer's set-up. If you have to install a C compiler, you probably won't bother. To me it's all a matter of the installer. Agreed. The installer should, IMHO, install almost everything (within reason). It makes more sense to have separate packages for stuff on Linux (that's the Linux way) but on Windows, people expect to be able to install 1 thing. Simons agruments, however, smell a lot of standard gimp extension language, because his goal is to have one language that is always pat of gimp, which would effectively be a standard. I don't think that's a bad idea at all, especially when we later think of macro recording and other tasks, where we _will_ need some standardized macro language that should be easy to translate into real scripts. Agreed. So - who's been thinking about the macro recorder? :) Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Updated roadmap (so people don't laugh at the old one)
Hi, Henrik Brix Andersen wrote: On Thu, 2004-02-05 at 13:27, Sven Neumann wrote: [...] nail us down [...] [snip] Imposing a fixed release schedule [...] [snip] [...] this road map should not be set in stone. I think both you and Sven have somewhat missed the point. The funny thing is, we are *almost* in agreement. I'm not trying to nail anyone down. I don't think anyone is. I'm not *imposing* anything. The roadmap (as has been shown by the last one) is *not* set in stone. However, it is precise. I don't think this should be a stick we use to beat ourselves with. I don't think we should get upset if a release isn't done *exactly* on the 31st of March or whatever. But I think that we're more likely to be close to the bigger dates if we have smaller, closer dates to aim for. I also think that we should release regularly, regardless of whether we think things are ready or finished, because it's healthy for the project. Releasing should not be a big deal. It could be as simple as doing cvs tag GIMP_2_1_1 cvs diff -r GIMP_2_1_0 -r GIMP_2_1_1 the_diff In which case, there'd be no reason not to do it often. Currently, we impose a standard somewhat stricter on ourselves, which means that making a release takes a long time (it can take 7 or 8 hours on a fast machine). But who cares if that thing you wanted to fix didn't get done? It'll be done for the next release. A release is *not* a deadline, it's a liberation of the work of the last 2 weeks. It's no secret that the GIMP project is rather short on active developers these days (I haven't been very active myself lately either) - and I think setting a tight release plan/road map will only discourage new developers to start spending what little spare time they may have contributing to The GIMP. Well, myself and Sven are in agreement on the tight release plan, more or less. I think it might be a little too tight, and I personally would have aimed for a first pre-release for guadec, with a final 2.2 in August, but I think a 4 month release is possible. The *only* difference between my idea and yours and Sven's is that I think that giving concrete dates as rough guidelines for milestones is better than having bigger milestones every 6 weeks to 2 months. I respect that you don't want to have to stick to dates. Like I said, there will be no Stazi knocking on your door if you don't. The roadmap is meant to be specific, but flexible, in my mind. If the majority opinion is against that, I will re-do a vaguer roadmap with no precise dates. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Misnamed structure element in SFScript structure?
Hi, Dave Neary [EMAIL PROTECTED] writes: Including guile doesn't mean supporting it. As it is, there are a bunch of things we include that don't get much support because the original authors have gone their own way. This time we're not even talking about *pretending* that this is a GIMP thing - we set up a configure script that checks if there's a local guile installed, if there is it uses it, otherwise it calls configure make on its copy, and uses it in the GIMP. It is the same thing as we currently have, except that instead of George Carrette's SIOD, we'll be using GUILE. And this time, we will be using an official release of a scheme interpreter, not a GIMP modified copy. I don't see a downside. We don't include libpng or libjpeg or glib or gtk+. Why should we include guile? If we need guile for script-fu and you argue that script-fu needs to be part of the standard gimp tarball, then gimp needs to depend on guile. Where's the downside? In the long run we should move as much as possible out of the GIMP package. This will assure that we provide a stable and powerful API and will enable more extensions and plug-ins to be written. IMO moving script-fu out of the tree and putting it on the same level as gimp-perl and other language bindings is a very important thing to do. There is a certain point at which this is unreasonable. If we move all the C plug-ins out into another module, and all the brushes, patterns and other data to another module, and all the script-fu and python-fu to separate modules, we'd have a small, stripped down core, but a usable GIMP would be made up of 6 or 7 CVS modules, 6 or 7 packages to download, and 6 or 7 packages to maintain. This sounds like the right thing to do. I'd go even further and move the GIMP libraries into a seperate package as well. The casual user will not even notice the difference. Users can install a meta package, all packaging systems I am aware of support such a thing. But if we had all these separate modules and would even distribute libgimp separately, we would finally allow other apps to use our widgets and the image processing libary we are developing. Other apps like for example a video manipulation program could be developed around the gimp core. I'm afraid that moving all of the langauge bindings out of the core would only result in the bindings not being maintained as well. As it is, the Python bindings are in need of a bit of a work-over before 2.0, if I remember correctly, and script-fu itself is only getting the minimum of maintenance for it not to be broken. If it turns out the languages are not maintained outside the GIMP it is probably about time to get rid of them. Actually I believe that it is a lot easier for people to maintain and contribute to a smaller package like gimp-script-fu as it is for the GIMP maintainers to keep Script-Fu alive and decide what to do about contributions from others. Anyway - working towards a minimalist GIMP is kind of going away from what I'd like to see. This would a major shift in our goals and policies and it definitely needs more discussion. I'd be more interested in being pretty liberal about the patches and plug-ins we accept in the core, and get more plug-in authors involved in maintenance work and development. For that we need to define guidelines for getting a plug-in into the core, and get the word out that we're interested in more or less anything and everything to do with image processing. Hand in hand with that we would also need guidelines for when a plug-in would get dropped (temporarily?) from the distribution if it is unmaintained. If we have decent guidelines, this would add very little work for maintainers, who could just let plug-in authors take care of their own code. This is IMHO not a reasonable goal. At the moment we are doing it like this because we are afraid of finally cleaning up our codebase to a point where it becomes maintainable again. At the moment the GIMP tree is way too large. Not only from a maintainance point of view. I also believe that the casual user is struggling with the shear amount of plug-ins and modules we ship by default. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Misnamed structure element in SFScript structure?
On Thu, 2004-02-05 at 16:14, [EMAIL PROTECTED] wrote: Simons agruments, however, smell a lot of standard gimp extension language, because his goal is to have one language that is always pat of gimp, which would effectively be a standard. I don't think that's a bad idea at all, especially when we later think of macro recording and other tasks, where we _will_ need some standardized macro language that should be easy to translate into real scripts. I agree that we should have a standard gimp scripting language but nothing prevents us from having it in a separate package on which The GIMP depends on being installed - just as we depend on GTK+ being installed (and just as we will depend on GEGL being installed in a not too distant future). I believe the project would benefit from splitting stuff like script-fu, python-fu etc. out from the main source module into their own. Why? To make the GIMP source code more modular. IMO, modularity means easier to maintain, easier to grok for new developers - and the beauty of it all: a much better separation between the different modules. ./Brix -- Henrik Brix Andersen [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Misnamed structure element in SFScript structure?
Hi, Dave Neary [EMAIL PROTECTED] writes: Actually, most GIMP users probably get their GIMP from Jernej - OK - the GNU/Linux side of things gives us a nice big install base on Linux, but proportionately very few Linux people actually *use* the GIMP. I'd guess that the majority of our power users are on Win32. Are there any numbers you can base this statement on? I don't think this assumption is correct. Not that it would matter much but I doubt there are more Win32 GIMP users than Linux GIMP users. I'd also like to get an idea of the number of MacOS X GIMP users. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Updated roadmap (so people don't laugh at the old one)
Hi, Dave Neary [EMAIL PROTECTED] writes: I'm not trying to nail anyone down. I don't think anyone is. I'm not *imposing* anything. The roadmap (as has been shown by the last one) is *not* set in stone. We all know that but your roadmap gave a different impression. Instead of pointing out what we want to achieve you gave a list of dates. Since we will not match a single one of these dates, it doesn't make sense to publish such a list. Releasing should not be a big deal. It could be as simple as doing cvs tag GIMP_2_1_1 cvs diff -r GIMP_2_1_0 -r GIMP_2_1_1 the_diff In which case, there'd be no reason not to do it often. Currently, we impose a standard somewhat stricter on ourselves, which means that making a release takes a long time (it can take 7 or 8 hours on a fast machine). But who cares if that thing you wanted to fix didn't get done? It'll be done for the next release. A release is *not* a deadline, it's a liberation of the work of the last 2 weeks. Doing the release tarball takes about half an hour. What takes time is to test it, to upload the tarball, put it on the FTP site, add a bugzilla version, change www.gimp.org to point to the new release, announce the release on freshmeat, gnomedesktop.org, linuxartist.org ... You can hardly cut down much of this. But I don't see what you are trying to argument about here. We agreed that we will do regular releases, we are already doing releases every two or three weeks. The point is just that I don't want to have a list that tells me that a release is pending next sunday. I know very well when it is about time for a release. When the time has come, I can figure out if the source is in a reasonable state for a release. Then I can try to find time to do it. If someone else would be doing the release it would be the very same thing. Now what good does it do if we tell people some release date that we are not likely to ever meet? Well, myself and Sven are in agreement on the tight release plan, more or less. I think it might be a little too tight, and I personally would have aimed for a first pre-release for guadec, with a final 2.2 in August, but I think a 4 month release is possible. The *only* difference between my idea and yours and Sven's is that I think that giving concrete dates as rough guidelines for milestones is better than having bigger milestones every 6 weeks to 2 months. All I can say is that a concrete release date discourages me to the point where I decide that I will rather be doing something else. As Brix said, there are enough deadlines in our lives. If GIMP starts to add more, then for me it's about time to quit with GIMP development. I just couldn't stand it. I respect that you don't want to have to stick to dates. Like I said, there will be no Stazi knocking on your door if you don't. The roadmap is meant to be specific, but flexible, in my mind. If the majority opinion is against that, I will re-do a vaguer roadmap with no precise dates. Some real content in the roadmap instead of meaning-less dates would be helpful. At perhaps make it a proposal for a roadmap next time. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Misnamed structure element in SFScript structure?
Hi, Sven Neumann wrote: Dave Neary [EMAIL PROTECTED] writes: I'd guess that the majority of our power users are on Win32. Are there any numbers you can base this statement on? No, it's a guess. Not that it would matter much but I doubt there are more Win32 GIMP users than Linux GIMP users. It's possible. I'd also like to get an idea of the number of MacOS X GIMP users. I'd say not many. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Gimp on OS X (was: Re: Misnamed structure element in SFScript structure?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 5, 2004, at 5:20 pm, Sven Neumann wrote: Are there any numbers you can base this statement on? I don't think this assumption is correct. Not that it would matter much but I doubt there are more Win32 GIMP users than Linux GIMP users. I'd also like to get an idea of the number of MacOS X GIMP users. FWIW I'm using GIMP 1.2 under OS X and suspect that there might be a few freaks who do so, too simply because it's easily to install if there's fink on the machine. On the other hand there're probably not to many professionals doing this because fink is too much Unixish for UI attracted persons and Photoshop is still the standard; and no, Mac professionals normally don't care much about prices as far as maximum productivity and creativity is concerned. I do realize that things are shifting a bit now that Macs start providing better bang for the buck. :) BTW: In OSX gtk 2 has really sucky rendering performance compared to gtk 1. I haven't tried GIMP v2 as of yet but other applications' UIs like gnumeric and evolution are simply slow on my new PowerBook which is certainly not a weak performer. FWIW one can feel the performance difference between my old PowerBook under Linux and the new PowerBook under OS X with the same applications. This is quite a showstopper for GIMP v2. Unfortunately I've no idea how to profile the X communication to possibly find the bottleneck. Any ideas? - -- Servus, Daniel -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (Darwin) iQEVAwUBQCJ5EDBkNMiD99JrAQLMWggAwplnURivogW16c4EeeXs/c6kRnd6h72u ym5jEIERhdW8nnHjvBrcgaJXBpJV2S/A5ykny9OX7dGiz44TZ6xrX9riJsPIj74P +MTN4cmcyHjrzUybHX4h3wbv/cbc59LoZY1freDWo1HMdt5+kbJdPMSD6hvgUjs0 1pii3ZMy6iPM/C+936H9EDjlJLm5vG2FCPD4vwaSKHDEs3tEeXstlnXsQClvi1eO IB9HSY2/0qVNFnCZZl+xZpaBnAxsqg+r8Z168WeltNNC8zThPyQQYooxL2u9xrhW pXe983du5k2EsET5Z4iKZL3lUd+Cq0CS4wH4AJfp/OwzZL7R5vxs9A== =EGy7 -END PGP SIGNATURE- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Update
Le mer 04/02/2004 à 14:53, Dave Neary a écrit : Hi, Hello, Would it be possible for the dcs team to do occasional update reports like I've tried to do over the past few months? It's easy to forget about ye, because all too often we don't look at the docs until there's a release. Roman did an update recently, and it would be nice if this became a regular feature, just to let us know who to thank :) We are using the Wiki to know who works on what : http://wiki.gimp.org/gimp/GimpDocsWip May be we could change this and have our own mailing-list like gimp-web. The Authors are listed here : http://wiki.gimp.org/gimp/GimpDocs Update reports or release ? You know my opinion, we are not ready for that. @+ Raymond ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp on OS X
Hi, Daniel Egger [EMAIL PROTECTED] writes: FWIW I'm using GIMP 1.2 under OS X and suspect that there might be a few freaks who do so, too simply because it's easily to install if there's fink on the machine. Installing gimp2 should be about as easy nowadays. BTW: In OSX gtk 2 has really sucky rendering performance compared to gtk 1. I haven't tried GIMP v2 as of yet but other applications' UIs like gnumeric and evolution are simply slow on my new PowerBook which is certainly not a weak performer. FWIW one can feel the performance difference between my old PowerBook under Linux and the new PowerBook under OS X with the same applications. This is quite a showstopper for GIMP v2. Do you use XFree or the X-Server that Apple provides? Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Win GIMP
Please note that GIMP does MDI (multiple document interface) already, it just doesn't folllow the WiW (window in window) approach that some people seem to prefer for obscure reasons. Every reference I've ever seen to MDI refers to window in window. I don't understand the purpose of that at all (and I happen to really detest it, in any event, since it wastes a lot of screen space). When using the GIMP I prefer to have the document window maximized. On windows this means that the Toolbox will get pushed behind and it is extremely awkward and I believe this is a significant part of the problem that most users want solved. Something as simple as an always on top option for the toolbox might be enough to make things easier for users like me who occasionally use crappy window managers. Speaking of maxmising the avialable workspace and it does seem to be of interst to more users than just me (I love the fullscreen mode by the way and) is there any way to hide the scrollbars? I would like to be able to get rid of the scrollbars and use keys for scrolling* up and down the page or alternatively use the overview/navigation widget. [the following bug is asking for the ability to use specific keys for scrolling, currently there doesn't seem to be ANY way to assign ANY keys at all to scrolling http://bugzilla.gnome.org/show_bug.cgi?id=53988 ] Sincerely Alan Horkan http://advogato.org/person/AlanHorkan/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Misnamed structure element in SFScript structure?
hiya, On Thu, Feb 05, 2004 at 03:42:24PM +0100, Simon Budig wrote: Ooops, that should have been gone to the ML as well... Sven Neumann ([EMAIL PROTECTED]) wrote: Simon Budig [EMAIL PROTECTED] Include a GUILE in the Gimp sourcecode, make sure that it doesn't conflict with other GUILEs on the target system and use it as the GIMPs default language. Perfectly fine with me as long as I have a language that is guaranteed to be available for 99% of the GIMP installations. I don't think we should do that simply because I don't see what is so important about having a self-contained scripting language. I'd rather like to see three or four well-maintained and working scripting languages that can be installed separately. It is pretty easy to see why a default scripting language is important, and I guess it is your grumpiness against script-fu that prevents you from seeing it. When somebody on IRC has a problem that is cumbersome in the UI, but can be solved with three or four PDB calls (e.g. Flip Layer menu entry) I'd hate to tell him that he has to install a monster like Perl/Python or whatever, to be able to use my quickly hacked three line solution. And even if he has Perl installed, I could not provide a script for him, because I only know about Python and Script-Fu. I don't want to be a master in all bindings available for gimp, just to be able to provide such a thing. I want to focus on one or two languages. This has happened in the past and Script Fu was a nice solution for stuff like that. And that is the reason why it is important to have a simple language available always. okay, i dont really like script-fu. i cant read it and it has this way of not telling gimp when it has made an image. yet, even if there is one user of gimp on windows, these users are used to one button making of images and some of the functions that the scripts give to gimp. i think there would be a lot more griping and tutorial pointing if you do anything to make it so it is difficult to install the script thing. about guile, do we even know those people? carol ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Win GIMP
Hi, Alan Horkan [EMAIL PROTECTED] writes: When using the GIMP I prefer to have the document window maximized. On windows this means that the Toolbox will get pushed behind and it is extremely awkward and I believe this is a significant part of the problem that most users want solved. Something as simple as an always on top option for the toolbox might be enough to make things easier for users like me who occasionally use crappy window managers. The code is already prepared to use gtk_window_keep_above() but we will need GTK+-2.4 for this so this will have to wait for GIMP-2.2. Speaking of maxmising the avialable workspace and it does seem to be of interst to more users than just me (I love the fullscreen mode by the way and) is there any way to hide the scrollbars? Sure, it's in the View menu and you can configure the default appearance (for fullscreen and normal view) in the preferences dialog. I wonder why you didn't look there. I would like to be able to get rid of the scrollbars and use keys for scrolling* up and down the page or alternatively use the overview/navigation widget. [the following bug is asking for the ability to use specific keys for scrolling, currently there doesn't seem to be ANY way to assign ANY keys at all to scrolling http://bugzilla.gnome.org/show_bug.cgi?id=53988 ] I might be wrong but shouldn't you be able to specify keys for scrolling using GTK+ bindings? Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Updated roadmap (so people don't laugh at the old one)
Hi, First, I'd like to say that I think it's a pity that you replied so aggressively to the mail - I would have liked to hear more comments, but I think that the tone of the thread may have intimidated people somewhat. Sven Neumann wrote: We all know that but your roadmap gave a different impression. Instead of pointing out what we want to achieve you gave a list of dates. Since we will not match a single one of these dates, it doesn't make sense to publish such a list. I am convinced that if we make releases conditional on a feature set that we will not have a 2.2 in 2004. If we're not making our major releases based on a feature set, then the only alternative is to make releases time-based. This has worked for other projects, I think it can work for ours. Doing the release tarball takes about half an hour. What takes time is to test it, to upload the tarball, put it on the FTP site, add a bugzilla version, change www.gimp.org to point to the new release, announce the release on freshmeat, gnomedesktop.org, linuxartist.org ... You can hardly cut down much of this. You can certainly spread it around. I update the NEWS now, as well as you. Anyone can do that. Same thing goes for making the announcement on freshmeat, gnome-desktop, linuxartist... I can do bugzilla tags. Anything which requires specialist knowledge (make distcheck, as you have pointed out, requires a finely balanced set of versions for a bunch of stuff, and there are very few people who understand the website system) or permissions (uploading the tarball) is another matter, but it doesn't make sense in general to have only one person able to do these things. The thing which takes the longest for *me* is make distcheck. But I don't see what you are trying to argument about here. We agreed that we will do regular releases, we are already doing releases every two or three weeks. The point is just that I don't want to have a list that tells me that a release is pending next sunday. I got the point; so I'll repeat mine, and then we can stop. We're more or less agreed that to have 2.2 by the end of June, we need to 1) have 2.0 this month 2) Branch a stable development branch next month 3) Feature freeze at the start of April 4) start pre-releases in the middle of April 5) Release 2.2 the end of June. I don't think there's any argument there. All I did was throw in a release every couple of weeks between those 5 points. I think it's helpful to show how little time there will be in this development cycle. Some real content in the roadmap instead of meaning-less dates would be helpful. At perhaps make it a proposal for a roadmap next time. This comment got me angry. I've calmed down now. Everything I post to this list that isn't meant to be a fact is an opinion, and a request for comments. If I say March 17th is St. Patrick's Day, that's a fact. If I say I think we should have 2.2.0 at the end of June, and I think this is more or less how to get there, that's opinion. See the difference? I asked for comments. I even got a couple of positive ones, in e-mails off-list. How much more proposally would you like it to be? Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Tentative 2.2 feature list
Hi all, After the time-based roadmap that I set yesterday, and the reaction to it, both Sven and brix said that they would have preferred more content. Well, here goes... Note, I believe that a time-based release is the way to go. That means I think it's better to say that we will have a release in the Summer than to say that (say) plug-ins will all have presets. That said, here's what I think is a reasonable target feature set for 2.2: 1) Migration to GTK+ 2.4, including - File selector upgrade (allows things like bookmarks) - remove all GtkOptionMenus - use GtkActions for shortcuts 2) Cut Paste across other applications including at least - image/pnm (raw, uncompressed data) - image/png (compressed data, slower copies) - image/svg+xml (sodipodi, OO Draw and InkScape would be cool) 3) Edit patterns in-place 4) Save as GIMP Pattern saves direct to ~/.gimp-1.3/patterns (same for Save as GIMP brush) 5) Preview widget to replace GimpOldPreview 6) User-defined presets for most plug-ins 7) Move from SIOD to guile for script-fu 8) Complete help On the list of maybe stuff, there's: 9) A decent image browser/thumbnail viewer + cover-sheet support 10) Macro recorder, if anyone has ideas on how it can be done with the current PDB/undo system Things I'd like to see someone try: 11) Layer groups, if there's an easy way to do them with the current code (I know these are easy with gegl, but gegl's over a year away, more than likely) 12) A few types of operations on an effects layer (idem - this can be done in a hackish way for a limited number of common operations pretty easily, I think, and that will be enough for most people's needs) This is a start of a feature list, and some stuff on this list will not get done, and some stuff not on the list will get done. There are a number of good patches waiting in Bugzilla to be applied as soon as we branch, which will give us a nice start for the first unstable release. On the policy side, here's how I would like things to be handled in 2.1.x: - Every feature added to CVS has a bug # associated with it - Every feature on the feature list is cut up into a number of independant bits (for example) migrating to gtk+ 2.4 is really 3 or 4 different jobs, not all of these need to be done by the same person) - Features should be prioritised, and the priorities more or less respected. What I mean by this last one is that for me, the only 2 features in here which I consider very important for 2.4 are inter-application copy paste and GTK+ 2.4 migration. The rest is more or less candy. I would hope that if people have some spare time that they'd choose to work on things which are considered more important, rather than work on other stuff. So there you have it, my ambitious view of what might get done in 6 weeks. But I think that we should be hard on ourselves... if features are not finished by the time we get to feature-freeze, we should not be afraid to back out some unfinished stuff, attach the patch that was backed out to the bug associated with the feature, and set the milestone for 2.4/3.0. Of course, we should do this nicely after asking the person whether they think they'll get the thing finished in the next couple of weeks. We're not going to get our knickers in a twist over a couple of features that slip past a date by a couple of weeks. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] [br@linuxnews.pl: [Gimp-user] another prob with parasites and script-fu]
hi, this was mailed on the gimp user list. thanks, carol - Forwarded message from Irek S?onina [EMAIL PROTECTED] - My previous problem with parasites in script-fu has dissapeared in new pre3 version (thanks Sven for URL to bugreport), but now I have one another: I tried to define gimp-comment parasite as defined in devel-docs/parasites.txt as PERSISTENT, but this causes an execution error of the script, as well as other defines commented below, with which I have tried to run the script: (define (script-fu-xcf2gif infile outfile) (let* ( (img (car (gimp-file-load 1 infile infile))) (drawable (car (gimp-drawable-get-image img))) ; (parasite (list gimp-comment GIMP_PARASITE_PERSISTENT some comment)) ; (parasite (list gimp-comment IMAGE_PERSISTENT some comment)) ; (parasite (list gimp-comment PERSISTENT some comment)) (parasite (list gimp-comment 1 some comment)) ) (gimp-image-flatten img) (gimp-image-parasite-detach img gimp-comment) (gimp-image-parasite-attachi img parasite) (gimp-image-convert-indexed img 1 0 256 0 1 ) (file-gif-save 1 img drawable outfile outfile 1 0 0 0) ) ) from libgimpbase/gimpparasite.h: #define GIMP_PARASITE_PERSISTENT 1 so I have tried to use direct the value of it instead of define, this works (script is executed successfully) but comment is not saved in gif: [EMAIL PROTECTED] ufki]$ identify -verbose blokada.gif|grep comment [EMAIL PROTECTED] ufki]$ Is this a bug or am I doing something wrong? If I should rather go to gimp-devel or somewhere else group please let me know. br. ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user - End forwarded message - ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Tentative 2.2 feature list
On Thu, 2004-02-05 at 17:12, David Neary wrote: 9) A decent image browser/thumbnail viewer + cover-sheet support This sounds a bit like the old GUASH (which I have started to port to GTK+ 2.x/GIMP 2.0) but I'm not sure what you mean by cover-sheet support. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] ANNOUNCE: GIMP 2.0 pre3
Hi there, what could be a reason for very slow cut'n resize function when I select region to be resized ? I noticed such behaviour after 1.3 version. I have standard slackware distribution with gtk 2.2 installed. Oleg On Wed, 4 Feb 2004, David Neary wrote: Hi all, The latest pre-release of the upcoming 2.0 GIMP is hot off the presses and available for download now at ftp://ftp.gimp.org/pub/gimp/v2.0/testing/ or from one of the mirrors listed at http://gimp.org/download.html Screenshots of some of the features available in the shiny new GIMP are at http://developer.gimp.org/screenshots.html We fixed a bunch of bugs, and we have another bunch to fix, and we're sure we haven't found them all yet. If you find any for us, please report them to http://bugzilla.gnome.org, against the GIMP product. We really do appreciate it. A special mention goes out to the GIMP Animation Package from Wolfgang Hofer, available here ftp://ftp.gimp.org/pub/gimp/plug-ins/v2.0/gap/testing/ The plug-in has recently had a 2.0 pre-release of its own. This plug-in is the best thing sinced sliced cheese. Screenshots are available (in French) at http://gimp-fr.org/html/mongimpfr/gap/gap2.html Happy GIMPing, Dave. Bugs fixed in GIMP 2.0pre3 == - 127451: Anchor floating selection when creating a text layer (Mitch) - 50649: Allow to call script-fu scripts from plug-ins (Mitch) - 132617: Improved gimp-remote behaviour (Sven) - 132036: Fixed issues with libart scan conversion (Simon) - 132041: Made info window not grab the focus (Mitch) - 132077: Redraw layer boundary when using transform tools (Mitch) - 132089: Flip tool misbehaviours (Mitch) - 132032: User interface issues with Plugin Details (David Odin) - 132145: Use default values when stroking from the PDB (Mitch) - 132162: Anchoring a floating selection on a channel (Mitch) - 132271: Mosaic filter on selections (Simon) - 132322: gimp-levels on grayscale images (Mitch) - 132329: Info window doesn't show inital values (Shlomi Fish) - 118084: Info window not updated in automatic mode (Shlomi Fish) - 132495: Positioning of glyphs that extend the logical rectangle (Sven) - 108659: Use g_spawn in postscript plug-in (Peter Kirchgessner) - 132508: Problems with path tool in Edit mode (Simon) - 132504: Fixed unsharp mask script (Mitch) - 132595: Don't draw the selection if it's hidden (Sven) - 132027: Crash in gimpressionist (Sven) - 132596: Use default values for color DND (Mitch) - 132493: Tuned Comic Logo script (Pedro Gimeno) - 132649: Allow to fill the whole selection using bucket-fill (Mitch) - 131902: Improved handling of missing tags in TIFF loader (Andrey Kiselev) - 93806: Validate script-fu input (Yosh) - 132214: Differentiate writable and readonly data directories (Mitch) - 131964: Zoom ratio problem (Simon) - 132969: Set help-id for tool on tool options dock (Mitch) - 132999: Make assembler code PIC safe (Yosh) - 119878: Use the same keyboard shortcuts in all GIMP windows (except the toolbox window) (Mitch) - 131975 - 132297: Disable some warnings while loading TIFFs (Raphael) - 129529: Add a randomize toggle to random number widget (Dave Neary) - 133099: Duplicate PDB entries problem (Mitch) - 133122: Disallow renaming of layer masks and some floating selections (Mitch) - 130118: Allow non-UTF8 characters in the GIMP home directory (Mitch) - 122026: Workaround a bug in gdk_draw_segments() (David Odin) - 133280: Remove deleted scripts from the menu (Mitch) - 133270: Replace deprecated enum values in scripts (Kevin Cozens) - 133180: Sort menu entries for save and load procedures (Mitch) - 131563: Use percentages for zoom ratios (Simon, Sven) Other contributions: Manish Singh, Tor Lillqvist, Jakub Steiner, Michael Natterer, Sven Neumann, Kevin Cozens ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
