[Gimp-developer] GIMP 2.0.0. out, gimp.org dead?
As some of you may have noticed, for a short while there was a www.gimp.org that claimed a release of GIMP 2.0.0., and Slashdot confirms it, so it may be true. The corpse of the Slashdot story has grown decidedly cold and rigid, yet http://www.gimp.org still seems to be down (or just very, very slow). From my mind to your mind, here's a nice picture for those who need that sort of thing: Bezig met tracen van route naar www.gimp.org [128.32.112.246] voor maximaal 30 hops: 119 ms12 ms10 ms 195.190.241.44 210 ms13 ms14 ms 42.ge-2-0-1.xr2.d12.xs4all.net [194.109.5.201] 313 ms14 ms14 ms 0.so-2-3-0.xr1.sara.xs4all.net [194.109.5.106] 411 ms10 ms10 ms asd-sara-ias-ur10.nl.kpn.net [194.109.7.226] 511 ms11 ms11 ms asd-dc2-ias-ur10.nl.kpn.net [195.190.227.7] 628 ms29 ms29 ms ldn-kq-ias-pr10.uk.kpn.net [194.151.244.192] 7 107 ms 110 ms 109 ms 195.66.224.185 8 107 ms 105 ms 108 ms p6-0.core02.jfk01.atlas.cogentco.com [154.54.1.5] 9 106 ms 108 ms 105 ms p12-0.core02.jfk02.atlas.cogentco.com [66.28.4.169] 10 128 ms 129 ms 125 ms p14-0.core02.ord01.atlas.cogentco.com [66.28.4.86] 11 129 ms 129 ms 129 ms p15-0.core01.ord01.atlas.cogentco.com [66.28.4.61] 12 173 ms 169 ms 169 ms p5-0.core01.sfo01.atlas.cogentco.com [66.28.4.185] 13 168 ms 169 ms 169 ms p15-0.core02.sfo01.atlas.cogentco.com [66.28.4.70] 14 168 ms 167 ms 169 ms CENIC.demarc.cogentco.com [38.112.6.226] 15 168 ms 169 ms 166 ms inet-ucb--lax-isp.cenic.net [137.164.24.142] 16 169 ms 169 ms 169 ms vlan194.inr-202-doecev.Berkeley.EDU [128.32.0.251] 17 173 ms 170 ms 169 ms doecev-soda-br-6-4.EECS.Berkeley.EDU [128.32.255.170] 18 168 ms 173 ms 173 ms sbd2a.EECS.Berkeley.EDU [169.229.59.226] 19 *** Timeout bij opdracht. -- branko collin [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] making plans
Hi, now that 2.0.0 is released, it's about time to make some plans for the future. IMHO, we should try to come up with a roadmap that is clear and detailed for the next months and reasonably vague for the time thereafter. We can then make precise plans for the time after 2.2 at GimpCon. I am going to propose a very short-term plan here. Feel free to comment on it and don't be afraid to use fighting words. Just tell me that my plan is wrong if you think that's the case. - Do a 2.0.1 release in about two weeks. We got a couple of bugs on the 2.0.1 milestone and I expect more problems to be reported during the next days. So there's plenty of work to do for 2.0.1. And IMO we should not branch CVS before 2.0.1 is released. That will save us some work on merging changes and it means that there's more pressure to get 2.0.1 out. - Do a 2.2 release in about three months. That seems like a short release cycle but I think that's exactly what we need at the moment. There are some unfinished things in 2.0 that could be done in 2 months of development. And we should be able to release w/o months of bug-fixing if we only have two months to introduce new bugs. Of course before we decide to attempt to have 2.2 ready by GimpCon (June 28 - 30) we should collect a more detailed list of changes that we would like to see in 2.2. I will spend some time with Bugzilla and try to prepare such a list... Sven ___ 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: - 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). One example of something which would definitely miss 2.2 if we release in June is libpdb. libpdb is being developed outside of The GIMP. As soon as it is ready it shouldn't take more than a few days to add it as an optional plug-in API. You cannot replace the current system with it anyway since we don't want to break the plug-in API for 2.x. and I doubt that a preview widget would make it in either (it would depend on the amount of free time David Odin has, and how well he can co-ordinate with Ernst). Same goes here. If we can settle on a design and an API in time, then it shouldn't be a problem to get the code in. If not, it will have to wait till 2.4. Setting up a 3 month release cycle sets us up for GTK+ 2.4 migration, committing outstanding features with patches attached, and maybe re-arranging the menus again. I don't see any major features going in in such a short cycle. Exactly. It would mean that we would be able to deliver a GIMP2 that uses the new GTK+ file-selector, we could improve our menus by using GtkAction and we could finish the outstanding text and path tool issues. If libpdb, the preview widget or any other features are ready in time, they can go in as well. Sounds like a good plan to me. Plus one of the objectives of 2.2 was to have complete coverage for docs - that seems unrealistic for June. What docs are you refering to? I would prefer to see us set ourselves up for a 6 month cycle and stick to it, rather than a 3 month cycle that we know is going to end up as 6 months in the end. If you are going to put a revamped PDB, the preview widget and a couple more things on our feature list, then you risk not to be able to stick to the 6 month cycle. For this reason, I'd rather like to go for a very short release cycle this time. Let's see how this works out and it would give us the chance to discuss new stuff on GimpCon. 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?
On 25 Mar 2004, Sven Neumann wrote: Hi, Branko Collin [EMAIL PROTECTED] writes: As some of you may have noticed, for a short while there was a www.gimp.org that claimed a release of GIMP 2.0.0., and Slashdot confirms it, so it may be true. The corpse of the Slashdot story has grown decidedly cold and rigid, yet http://www.gimp.org still seems to be down (or just very, very slow). The new machine seems to have some problems. It remains to be figured out what kind of problems. But it went alive yesterday after the slashdot attack and when it's there, it's very responsive :) No idea why it's not avaiable at the moment, but rest assured, we know about the problem and it will be taken care of. Also, urls like http://www.gimp.org/~tml don't work, but you probably already knew that. http://wilber.gimp.org/~tml does work still. Rockwalrus ___ 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 [EMAIL PROTECTED] writes: Also, urls like http://www.gimp.org/~tml don't work, but you probably already knew that. http://wilber.gimp.org/~tml does work still. It works again now. 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?
On 25 Mar 2004, Sven Neumann wrote: Hi, Nathan Carl Summers [EMAIL PROTECTED] writes: Also, urls like http://www.gimp.org/~tml don't work, but you probably already knew that. http://wilber.gimp.org/~tml does work still. It works again now. Hmm, not for me: Not Found The requested URL /~tml/index.html was not found on this server. Additionally, a 500 Internal Server Error error was encountered while trying to use an ErrorDocument to handle the request. Apache/1.3.26 Server at mmmaybe.gimp.org Port 80 Rockwalrus ___ 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 [EMAIL PROTECTED] writes: Not Found The requested URL /~tml/index.html was not found on this server. IIRC the URL is either http://www.gimp.org/~tml/gimp/win32/ or http://www.gimp.org/win32/. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
Hi, On Thu, 2004-03-25 at 15:55, Sven Neumann wrote: now that 2.0.0 is released, it's about time to make some plans for the future. IMHO, we should try to come up with a roadmap that is clear and detailed for the next months and reasonably vague for the time thereafter. We can then make precise plans for the time after 2.2 at GimpCon. Yes, this sounds like a decent approach for the time to come. - Do a 2.0.1 release in about two weeks. We got a couple of bugs on the 2.0.1 milestone and I expect more problems to be reported during the next days. So there's plenty of work to do for 2.0.1. And IMO we should not branch CVS before 2.0.1 is released. That will save us some work on merging changes and it means that there's more pressure to get 2.0.1 out. I agree that we should not branch CVS before after 2.0.1 is released. We need to focus on fixing the worst of the bugs in 2.0.0. Hopefully this will help us avoid the 'lets break everything and work on new features' mania. :) - Do a 2.2 release in about three months. That seems like a short release cycle but I think that's exactly what we need at the moment. There are some unfinished things in 2.0 that could be done in 2 months of development. And we should be able to release w/o months of bug-fixing if we only have two months to introduce new bugs. Of course before we decide to attempt to have 2.2 ready by GimpCon (June 28 - 30) we should collect a more detailed list of changes that we would like to see in 2.2. I will spend some time with Bugzilla and try to prepare such a list... A 3 months release cycle for 2.2 sounds reasonable to me. This will give us enough time to fix the outstanding bug reports and we will have time at GIMPCon2004 to discuss a road map for 2.4. 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] making plans
Hi, before we go into a sinless discussion on whether 3, 6 or 9 months would be an appropriate timeframe for 2.2, I'd like to propose a different approach. Let's collect what features we have in Bugzilla, what features people would like to work on, what time they think they would need and so on. When we have collected that list, it should be possible to come to a reasonable time schedule. What do you think? Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] making plans
On Thu, Mar 25, 2004 at 06:20:14PM +0100, Sven Neumann wrote: 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). I think so too. We should shore up the app and get it to a decent state before we really land the major new break everything features. One example of something which would definitely miss 2.2 if we release in June is libpdb. libpdb is being developed outside of The GIMP. As soon as it is ready it shouldn't take more than a few days to add it as an optional plug-in API. You cannot replace the current system with it anyway since we don't want to break the plug-in API for 2.x. 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. -Yosh ___ 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 Tue, Mar 23, 2004 at 01:22:23PM +0100, Marc Lehmann wrote: On Fri, Mar 19, 2004 at 02:19:09PM -0800, Manish Singh [EMAIL PROTECTED] wrote: While on that subject, I'm wondering what a good way of representing named parameters in scheme and perl would be. Any thoughts? This is natural, and common: $obj-method (arg1 = value1, arg2 = value2, ...) this, too: $obj-method (-arg1 = value1, -arg2 = value2, ...) as well as this: $obj-method (Arg1 = value1, Arg2 = value2, ...) All of these can be supported at the same time, and the difference between them is often seen as a style difference only. However, there is no way of using the same method both with named parameters or not (unless your resort to other syntaxes like $obj-method (ARG1, value1, ARG2, value2), making ARG1 etc. global or worse). Yeah, that is unfortunate, since the interface should support both named and positional interfaces (and combining the two in one call). Especially with methods with just a single argument, forcing named parameters might not be the best thing (OTOH, you can make a difference between methods with single argument and more, but...). Right now, a few things get autodetected because gimp-perl uses strong typing for the gimp objects (as opposed to e.g. C or scheme). All in all there would be no problem at all supporting named parameters (There is even a certain amount of support for that already in gimp-perl), but it will break existing scripts and make writing scripts slightly more tedious. Well, this would go hand in hand with a plugin api redo, so scripts are gonna break anyway. Personally though, I really want named parameters. Not at all because of me being able to remember arguments better (I think it's actually worse to have to remember the parameter names), but because it allows me to easily leave off arguments that can be defaulted. Most of these arguments, however, are at the end, so even more important than named parameters would IMHO be default values for unspecified ones. I once reworked the PDB code to allow variable number of arguments but left the check in for compatibility with existing plug-ins who expect all or nothing (ignoring the number of arguments actually passed; the API did provide this already). So what would be a good way for perl to support both named and positional stuff? The only way I can think of still is to use a hashref for named parameters. -Yosh ___ 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 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? Distributed processing will soon be supported by libpdb using the WireSocket backend; this will be done by early May. Implementing WireSocket is one of the group projects chosen by some of the students in a class I am taking, so it will be done if they want a good grade. :) Heh. Maybe local UNIX sockets are faster than pipes. Would be good to benchmark. UI generation is mostly out of the scope of libpdb. I would have to know more what is specifically meant by UI generation before I could comment on it. Generate a UI from a PDB entry. Like a generalized -fu that the scripting languages currently have. This makes an easy way of generating property panes for nodes in a graph say, made out of PDB nodes. Efficiency has yet to be addressed by libpdb, although some easy optimizations have been put in place. Serious optimization should probably wait until the feature requirements are more in place and reasonable profiling can be done. Yeah. For macro recording things should to go through the PDB in the app itself, so the within process boundary case things should be lightweight and fast. GEGL node support opens a big can of worms, and there probably is no best solution. The first big decision to make is whether plug-ins should be written as GEGL nodes objects directly, or whether there should be a shim GEGL node that translates the operations into procedural calls not unlike those in the traditional GIMP api. If we do use a translating shim, Libpdb seems like a good fit for this as well. Yes, that's undetermined. It seems like a real shame to lose GIMP's ability to run plug-ins out of process, so my vote is we rule out dynamically loading gegl nodes using GPlugIn as the only method, although we may want to be able to do it as an additional extra-fast method. CORBA seems like a flexible choice here if we decide to make plug-ins implemented directly as gegl nodes. Although my guess is it would add somewhat more overhead than a hand-rolled gimp-specific method, it has the advantage of being more flexible than anything we could do, and also it would be something maintained by an outside group instead of another burden for us. I dunno. CORBA is pretty heavyweight, there isn't an ORB out there that does things efficiently. If we do decide to have plug-ins be native GeglNodes, I recommend that we still have a PDB for scripting purposes. A node has inputs and outputs, and so do PDB functions, so there isn't much difference there. I've thought about doing a proxy GObject framework, which would allow IPC of arbitrary objects, but I haven't fleshed it out in my mind yet. One thing I've thought about would be to use the object and type system features, like every PDB function is an object, with properties for parameters. A paramspec has everything we need: type, name, descriptions, defaults, possible bounds. Maybe something like a PDB function is an object, you set properties on it, then run the execute method. Also have a print method for a textual representation. Then just instantiate and string together these objects, and run through then. Sort of like CellRenderers in GtkTreeView. This might be a complete and total abuse of the object system tho, and not scale at all. I might do a quicky implementation and see. Using paramspecs somehow is tempting though. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
