[Gimp-developer] gimp threated by monopoly rights (software patents)
Hallo folks, did you notice, that gimp is infringing the patents US-546528 and its EU pandant EU-689133 ? The owner Adobe is known to act with thuggery against everyone who may hurt the business interests, as the Sklyarov case clearly showed. The more Gimp is becoming a competitor against Adobe products, the more the possibility raises, that Adobe attacks the Gimp project and its developers. Details on the monopoly claims: http://swpat.ffii.org/patente/wirkungen/palette/index.en.html Today such monopolies on thoughts in form of software patents are illegal, but this didn't impede the EPO to grant more than 30.000 software patents - AGAINST THE JURISPRUDENTION. But the European Commission is fighting very hard to convert the illegal practice to law - ignoring the clear votum of the democratic elected European Parlament - and so not just extremly endangering the european IT industry, also negating the principles of intellectual freedom and democracy. Not just every developer, every human, is called for acting now and helping us to save our rights and prevent a new form of feudalism raising up in Europa! http://swpat.ffii.org/ http://petition.eurolinux.org/ Greets, -- e.weigelt, ceo metux IT service -- http://www.metux.de/ -- - Enrico Weigelt== metux IT services phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] cellphone: +49 174 7066481 - -- DSL-Zugang ab 0 Euro. -- statische IP -- UUCP -- Hosting -- - ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] PDB requirements
David Neary wrote: Perhaps I'm being over-simplistic, but couldn't we go for the partial solution of just recording plug-in events, via the existing PDB interface, and get ourselves most of the functionality that people need for very little effort? It's really not all that useful if we don't have paint event recording. Kelly ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: PDB named and default parameters (was Re: [Gimp-developer] The Mark Shuttleworth offer)
On Sat, Mar 27, 2004 at 03:27:04AM +0100, Marc Lehmann wrote: > On Thu, Mar 25, 2004 at 07:48:59PM -0800, Manish Singh <[EMAIL PROTECTED]> wrote: > > So what would be a good way for perl to support both named and positional > > stuff? > > It simply shouldn't. It should either do positional where it is useful > and named where it is useful. Or always named. Everything else (like a > hashref) is just madness and should be handled by a different interface > (call_procedure_hashref...). > > Please note that it doesn't make _any_ sense to have 100% named parameters > for the majority of functions (e.g. all fucntions having an image, or > layer etc. as leading arguments, as these should be handled using method > syntax). No, but it's nice to be flexible and have the option of doing things with method syntax or procedural syntax. Isn't an important Perl motto TMTOWTDI? :) Perhaps the OO syntax should always expect named parameters, but non-OO syntax should offer both in some fashion, like a hashref, or some sort of marker to say "named parameters start here". > Most languages share this problem, so it would be interetsing how this > would be solved in C for example (probably using a different interface). Python supports positional and named arguments natively, and we've talked about workable solutions in Scheme. In C it's a pain in the ass to call PDB functions at all, so no big deal to have two interfaces. But I'd like to do better in more dynamic languages. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] ANNOUNCE: Pre-releases for Perl bindings
On Fri, Mar 26, 2004 at 05:30:36PM +0100, Dave Neary wrote: > > Hi Carol, > > Carol Spears wrote: > >>On Fri, Mar 26, 2004 at 04:27:13PM +0100, Dave Neary wrote: > >>>Tino Schwarze wrote: > Is there a dedicated mailing list for Gimp-Perl? > >>> > >>>As far as I know there isn't (although Marc might correct me) - here is > >>>the best place. > >> > >>seth burgess has been working on this. > >> > >>thanks for your answer, however, mr. neary. articulate and wrong. > > As I said earlier - both Seth and Marc are here, and there is no > standalone gimp-perl list. So how exactly was my answer wrong? > eh, i dunno. is there something wrong with what i wrote about gimp-perl working somewhere? xoxox carol ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
On Fri, Mar 26, 2004 at 11:06:46AM -0600, Kelly Martin wrote: > > That's my two cents on the matter, at least. > can you give a nickels worth sometime? carol ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] PDB requirements
Hi, Kelly Martin wrote: > Manish Singh wrote: > >I was asking more in terms of an API should look like. Interactive > >paint is more involved than say, a bucket fill, which is easily translated > >into to "call PDB bucket fill function on button release". > > Especially when you consider the airbrush, which has time sensitivity as > well as motion sensitivity. > This is nonsimple to begin with, and making it efficient is even more > complex. You don't want substantial redraw delays while painting. I am not > sanguine on getting this implemented in the desired three month window. Perhaps I'm being over-simplistic, but couldn't we go for the partial solution of just recording plug-in events, via the existing PDB interface, and get ourselves most of the functionality that people need for very little effort? 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
Re: [Gimp-developer] PDB requirements
* Kelly Martin <[EMAIL PROTECTED]> [040326 21:12]: > Manish Singh wrote: > > >We could simply bypass the pdb for painting, and just emit "record this" > >on button release. But maybe it'd be better to have the pdb more involved, > >I dunno. > > You'd at least have to serialize all the events for the paintbrush and > airbrush if you want the macro to be brush- and color- independent (that > is, you are interested in capturing the motions used, rather than the > result). You could save the serialization in a buffer and then spew it > forth at the end, but I don't see any way around collecting the actual > paint events. Ideally you want to implement this code in an resolution independent manner as well. Thus all motion events should be interpolated in some manner,. when zoomed out drawing freehand shapes are guaranteed to create coordinate quantification in the shape, unless the coordinates are interpolated, and ideally translated to a curve. If a procedual GEGL operation is lying below,. you could just pass the controlpoints of the curve to the function,. at some level the bezier/spline curve could perhaps also be smoothed within a threshold, when using tools freehand, before passing it to the drawing op itself,. doing it in this manner allows parametric data to be cached for a more advanced and memory efficient undo op stack as well. > This was a requirement when I was asked to this by my former employer back > in 2000, and also a requirement for the guy who was trying to contract > Wilberworks to do it back in 1998. I think a macro recorder that doesn't > capture motion events will be of limited utility to users. -- .^. /V\Øyvind Kolås, Gjøvik University College, Norway /(_)\ <[EMAIL PROTECTED]>,<[EMAIL PROTECTED]> ^ ^ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] PDB requirements
Manish Singh wrote: We could simply bypass the pdb for painting, and just emit "record this" on button release. But maybe it'd be better to have the pdb more involved, I dunno. You'd at least have to serialize all the events for the paintbrush and airbrush if you want the macro to be brush- and color- independent (that is, you are interested in capturing the motions used, rather than the result). You could save the serialization in a buffer and then spew it forth at the end, but I don't see any way around collecting the actual paint events. This was a requirement when I was asked to this by my former employer back in 2000, and also a requirement for the guy who was trying to contract Wilberworks to do it back in 1998. I think a macro recorder that doesn't capture motion events will be of limited utility to users. Kelly ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] PDB requirements
On Fri, Mar 26, 2004 at 06:53:28PM +0100, Michael Natterer wrote: > >> Manish Singh <[EMAIL PROTECTED]> writes: > > Well, something has to generate those coords, and something has to update > > the UI before painting is finished. > > > > I was asking more in terms of an API should look like. Interactive > > paint is more involved than say, a bucket fill, which is easily translated > > into to "call PDB bucket fill function on button release". > > IMHO this is not a big issue, since even today PDB painting uses almost > the same functions as interactive painting does. The only difference > is that PDB painting flushes the stuff at the end while interactive > painting flushes while painting. > > So everything that would have to be changed is replacing the call > to gimp_paint_core_interpolate() by some_generated_pdb_paint_foo() > and flush the display in between. Not a big deal i'd say. > > (What I want to say is that painting has been abstracted well > enough to enable stroke recording without changing too much). > > But then you are right, maybe we need a new API because it's > perhaps cleaner to just draw the stuff as we do now and to > create the recorded entry on button_release() Right, it wouldn't be hard to adapt the code to do this. But we should nail down a sane API... We could simply bypass the pdb for painting, and just emit "record this" on button release. But maybe it'd be better to have the pdb more involved, I dunno. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] PDB requirements
Manish Singh wrote: I was asking more in terms of an API should look like. Interactive paint is more involved than say, a bucket fill, which is easily translated into to "call PDB bucket fill function on button release". Especially when you consider the airbrush, which has time sensitivity as well as motion sensitivity. The general paint UI (used for paint/pencil/erase, clone, smudge/dodge/burn, and airbrush, IIRC) has to generate an drawing event for each drag. The airbrush also has to generate one for each timer tick while the mouse is down, whether or not a drag occurred. The other tools generate only one drawing event, at mouse release. The lasso can probably only generate one drawing event, at mouse release, but its event structure is considerably more complex than the rest. I'm not sure about the various vector-related tools. This is nonsimple to begin with, and making it efficient is even more complex. You don't want substantial redraw delays while painting. I am not sanguine on getting this implemented in the desired three month window. Kelly ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] PDB requirements
Manish Singh <[EMAIL PROTECTED]> writes: > On Fri, Mar 26, 2004 at 12:06:33PM +0100, Michael Natterer wrote: >> Manish Singh <[EMAIL PROTECTED]> writes: >> >> > On Wed, Mar 24, 2004 at 08:58:39AM -0800, Nathan Carl Summers wrote: >> >> On Sun, 21 Mar 2004, Manish Singh wrote: >> >> > On Sun, Mar 21, 2004 at 09:44:25PM +0100, David Neary wrote: >> >> > > What requirements would the new PDB have? >> >> > >> >> > There's a number of issues to be addressed, like GEGL node support, >> >> > efficiency, UI generation, distributed processing, and macro recording >> >> > support. >> >> >> >> Macro recording is already trivial with libpdb: you just connect to the >> >> appropriate signal of the Pdb object. >> > >> > Have you given any thought on how to macroize interactive paint >> > functions? >> >> By simply passing an array of GimpCoords to the yet-to-be-generated >> core PDB wrappers, just as all core functions will have to be invoked >> via these wrappers to make marco recording possible. > > Well, something has to generate those coords, and something has to update > the UI before painting is finished. > > I was asking more in terms of an API should look like. Interactive > paint is more involved than say, a bucket fill, which is easily translated > into to "call PDB bucket fill function on button release". IMHO this is not a big issue, since even today PDB painting uses almost the same functions as interactive painting does. The only difference is that PDB painting flushes the stuff at the end while interactive painting flushes while painting. So everything that would have to be changed is replacing the call to gimp_paint_core_interpolate() by some_generated_pdb_paint_foo() and flush the display in between. Not a big deal i'd say. (What I want to say is that painting has been abstracted well enough to enable stroke recording without changing too much). But then you are right, maybe we need a new API because it's perhaps cleaner to just draw the stuff as we do now and to create the recorded entry on button_release() ciao, --mitch ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] PDB requirements (was: PDB named and default parameters)
On Fri, Mar 26, 2004 at 12:06:33PM +0100, Michael Natterer wrote: > Manish Singh <[EMAIL PROTECTED]> writes: > > > On Wed, Mar 24, 2004 at 08:58:39AM -0800, Nathan Carl Summers wrote: > >> On Sun, 21 Mar 2004, Manish Singh wrote: > >> > On Sun, Mar 21, 2004 at 09:44:25PM +0100, David Neary wrote: > >> > > What requirements would the new PDB have? > >> > > >> > There's a number of issues to be addressed, like GEGL node support, > >> > efficiency, UI generation, distributed processing, and macro recording > >> > support. > >> > >> Macro recording is already trivial with libpdb: you just connect to the > >> appropriate signal of the Pdb object. > > > > Have you given any thought on how to macroize interactive paint > > functions? > > By simply passing an array of GimpCoords to the yet-to-be-generated > core PDB wrappers, just as all core functions will have to be invoked > via these wrappers to make marco recording possible. Well, something has to generate those coords, and something has to update the UI before painting is finished. I was asking more in terms of an API should look like. Interactive paint is more involved than say, a bucket fill, which is easily translated into to "call PDB bucket fill function on button release". -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
On Fri, Mar 26, 2004 at 04:52:29PM +0100, Dave Neary wrote: > Hi, > > Sven Neumann wrote: > >Helps for what? If libpdb is not our PDB redesign, what is it then? > > What is it? Rock? > > I may be misunderstanding what it is, but I understood that libpdb was an > extra > layer between the existing (unchanged) PDB and plug-ins which allowed things > like named parameters, and sockets rather than shm for plug-in/core > communication. Looking at the code, there's no wrapping layer at all, it's pretty much a wholesale replacement. > Aside from those 2 things, I know nothing about it except that someone is > actively working on it, and that person was under the impression that it was > scheduled for inclusion in 2.2. AFAIK, Nathan made libpdb primarily so common PDB functionality could be shared between projects, and gimp isn't the sole customer. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
Dave Neary wrote: I could be convinced that having a release in 3 months is the right thing (I am under no illusions though - if I disagree with it, that won't necessarily influence the eventual decision). It would depend on the feature lists we compile over the next few days/weeks. I think a goal of a 2.2 release in three months is a good one, which means the feature list that gets accumulated should have anything that can't be implemented in that time removed from it. If that makes for too few features, then either add one or two more. I wouldn't push the release date back much more than that. That probably means that a feature freeze in one to two months is appropriate. There's a lot of little stuff that people have been holding off on; surely there's enough of those to fill the next three months. Save the Big Stuff for 2.4/3.0. That's my two cents on the matter, at least. Kelly ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
Hi William, William Skaggs wrote: If you plan for three months, it will take nine months, so you should plan for three months. If you plan for six months it will take over a year. Feynman's Law: Everything takes twice as long as you expect it will, even when you take into account Feynman's Law. The problem is that if you go way over schedule (that is, if we say 3 months, and we're still not at 2.2 in 6 to 8 months time), you end up moving to a feature-based thing. People start working on things which hadn't been planned and you end up with so much schedule creep that the old schedule is eventually ignored and forgotten (I think in 1.3 this happened sometime at the start of 2002, although I wouldn't be able to put my finger on a particular event). At which point you need to come up with a new plan. I could be convinced that having a release in 3 months is the right thing (I am under no illusions though - if I disagree with it, that won't necessarily influence the eventual decision). It would depend on the feature lists we compile over the next few days/weeks. But I would be worried that if we set off on too short a cycle that people will not start features which won't be done in 6 weeks. And we might only end up with 2 or 3 people working on 2.1.x, which would be a shame given that we are getting more & more people contributing code at the moment. I'm agreed that if we have features without someone to write them that they shouldn't hold up a 2.2 release, though. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
Hi, Joao S. O. Bueno wrote: would it be too troublesome to call this release that will just finish things that have started, as 2.0.X series, instead of a 2.2 ? IMHO, that would be fine - but the "just finish things" won't just finish things, it will add smallish features too. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-web] Re: [Gimp-developer] ANNOUNCE: Pre-releases for Perl bindings, Help pages and GAP + Win32 installer
Hi Carol, Carol Spears wrote: On Fri, Mar 26, 2004 at 04:27:13PM +0100, Dave Neary wrote: Tino Schwarze wrote: Is there a dedicated mailing list for Gimp-Perl? As far as I know there isn't (although Marc might correct me) - here is the best place. seth burgess has been working on this. thanks for your answer, however, mr. neary. articulate and wrong. As I said earlier - both Seth and Marc are here, and there is no standalone gimp-perl list. So how exactly was my answer wrong? Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
>> Would it be too troublesome to call this release that will just >> finish things that have started, as 2.0.X series, instead of a 2.2 ? > >Yes. Only bug-fixes in a stable release series. And for a more practical reason, it can't be done without branching, and you don't want to call both branches 2.0.X. Best, -- Bill __ __ __ __ Sent via the KillerWebMail system at primate.ucdavis.edu ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
If you plan for three months, it will take nine months, so you should plan for three months. If you plan for six months it will take over a year. Feynman's Law: Everything takes twice as long as you expect it will, even when you take into account Feynman's Law. Best, -- Bill __ __ __ __ Sent via the KillerWebMail system at primate.ucdavis.edu ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
Hi, Sven Neumann wrote: Helps for what? If libpdb is not our PDB redesign, what is it then? What is it? Rock? I may be misunderstanding what it is, but I understood that libpdb was an extra layer between the existing (unchanged) PDB and plug-ins which allowed things like named parameters, and sockets rather than shm for plug-in/core communication. Aside from those 2 things, I know nothing about it except that someone is actively working on it, and that person was under the impression that it was scheduled for inclusion in 2.2. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-web] Re: [Gimp-developer] ANNOUNCE: Pre-releases for Perl bindings, Help pages and GAP + Win32 installer
On Fri, Mar 26, 2004 at 07:37:23AM -0800, Carol Spears wrote: > On Fri, Mar 26, 2004 at 04:27:13PM +0100, Dave Neary wrote: > > > > Hi Tino, > > > > Tino Schwarze wrote: > > >Is there a dedicated mailing list for Gimp-Perl? I had troubles > > >installing this... It doesn't seem to work with the latest > > >ExtUtils::Depends ... And I'd like to have all these perl plug-ins back! > > > > As far as I know there isn't (although Marc might correct me) - here is the > > best place. > > > seth burgess has been working on this. > > i guess the perl stuff that is in debian sid will work. > > it would be nice to have a list of what is needed and put it online. > > thanks for your answer, however, mr. neary. articulate and wrong. > > carol > > ___ > Gimp-web mailing list > [EMAIL PROTECTED] > http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-web ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] ANNOUNCE: Pre-releases for Perl bindings, Help pages and GAP + Win32 installer
Hi Tino, Tino Schwarze wrote: Is there a dedicated mailing list for Gimp-Perl? I had troubles installing this... It doesn't seem to work with the latest ExtUtils::Depends ... And I'd like to have all these perl plug-ins back! As far as I know there isn't (although Marc might correct me) - here is the best place. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] ANNOUNCE: Pre-releases for Perl bindings, Help pages and GAP + Win32 installer
Hi there, On Thu, Mar 25, 2004 at 10:38:03PM +0100, Henrik Brix Andersen wrote: > Gimp-Perl is an extension for writing Gimp Extensions/Plug-ins/Load and > Save-Handlers in Perl. A Gimp-Perl pre-release is available on CPAN and > at ftp://ftp.gimp.org/pub/gimp/plug-ins/v2.0/perl/ Is there a dedicated mailing list for Gimp-Perl? I had troubles installing this... It doesn't seem to work with the latest ExtUtils::Depends ... And I'd like to have all these perl plug-ins back! Bye, Tino. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
Hi, Dave Neary <[EMAIL PROTECTED]> writes: > I think that if it's done, and works correctly, and is useful, we > should use it. Useful for what? What do you think libpdb is? We don't need to replace our working PDB code with other code that does the same thing. Unless I am completely wrong, what we are talking about here is a redesign of the way that plug-ins talk with the GIMP core. That's something that should be well done and it absolutely needs a stable API that isn't changed with the next release. Otherwise noone will ever port their plug-ins to it. > The PDB redesign is vaporware, and might not even be done before > gegl gets integrated. If libpdb helps in the meantime, I'm all for it. Helps for what? If libpdb is not our PDB redesign, what is it then? Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
Hi, "Joao S. O. Bueno" <[EMAIL PROTECTED]> writes: > Would it be too troublesome to call this release that will just > finish things that have started, as 2.0.X series, instead of a 2.2 ? Yes. Only bug-fixes in a stable release series. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
Hi all, Sven, would it be too troublesome to call this release that will just finish things that have started, as 2.0.X series, instead of a 2.2 ? JS -><- On Thursday 25 March 2004 14:20, Sven Neumann wrote: > Hi, > > Dave Neary <[EMAIL PROTECTED]> writes: > > > - Do a 2.2 release in about three months. > > > > I think that's unrealistically short at this stage. There are people > > who have said that they want to do some concrete and long-standing > > TODO items, and 6 weeks to 2 months is not enough time to get most > > of those done and debugged properly. > > IMHO we should rather try to finish what has started already and get > these new features to our users quickly. 2 months should be sufficient > to get that done. Whatever cannot be achieved in this time will have > to wait for the next release then (which could be by the end of the > year). >(...SNIP...) > Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
Hi, Manish Singh wrote: I don't think libpdb should land in 2.2, since I don't think we'll be able to nail down everything we need in a new PDB api in the timeframe, and it'd be kind of silly to land a brand new core API that'll only live for one release. I think that if it's done, and works correctly, and is useful, we should use it. I think we should avoid the temptation to think 1 release ahead - you say that it'll only live for 1 release, but that release might be around for a long time. At one stage there were similar things said early in the 1.3 release cycle (the effort on thing X wouldn't be worth it because it would be superceded by gegl anyway) - I don't recall exactly the features in question, but layer grouping comes to mind as one of the things suggested a couple of years back that is, imho, doable reasonably nicely with the current core. The PDB redesign is vaporware, and might not even be done before gegl gets integrated. If libpdb helps in the meantime, I'm all for it. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] PDB requirements (was: PDB named and default parameters)
Manish Singh <[EMAIL PROTECTED]> writes: > On Wed, Mar 24, 2004 at 08:58:39AM -0800, Nathan Carl Summers wrote: >> On Sun, 21 Mar 2004, Manish Singh wrote: >> > On Sun, Mar 21, 2004 at 09:44:25PM +0100, David Neary wrote: >> > > What requirements would the new PDB have? >> > >> > There's a number of issues to be addressed, like GEGL node support, >> > efficiency, UI generation, distributed processing, and macro recording >> > support. >> >> Macro recording is already trivial with libpdb: you just connect to the >> appropriate signal of the Pdb object. > > Have you given any thought on how to macroize interactive paint > functions? By simply passing an array of GimpCoords to the yet-to-be-generated core PDB wrappers, just as all core functions will have to be invoked via these wrappers to make marco recording possible. ciao, --mitch ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP 2.0.0. out, gimp.org dead?
Hi, Sven Neumann wrote: Either your DNS is stale or Yosh is moving the server again. Stay calm. In the end it will all work. I'm very calm :) It was just a piece of information. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP 2.0.0. out, gimp.org dead?
Hi, Dave Neary <[EMAIL PROTECTED]> writes: > Still not working for me. wilber.gimp.org/~tml... works fine. Either your DNS is stale or Yosh is moving the server again. Stay calm. In the end it will all work. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP 2.0.0. out, gimp.org dead?
Hi, Nathan Carl Summers wrote: On 25 Mar 2004, Sven Neumann wrote: IIRC the URL is either http://www.gimp.org/~tml/gimp/win32/ or http://www.gimp.org/win32/. Yeah, I know that. That url wasn't working either. Now it is. Perhaps some cache needed to expire. Still not working for me. wilber.gimp.org/~tml... works fine. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
