Re: [Gimp-developer] The Mark Shuttleworth offer
On 18 Mar 2004, at 16:38, Daniel Rogers wrote: So, More details have come forward about the Mark Shuttleworth offer. Mark Shuttleworth made up his mind and decided to fund myself and Calvin to work on GEGL and GIMP/GEGL integration. Until today, I didn't have any specific details on the offer. [etc.] Any news since last month? Your announcement was followed by a flurry of excited comments, but not much since. ESA putting a Dutch 'tourist' into space this week suddenly reminded me of Here Be Bounties. -- branko collin [EMAIL PROTECTED] ___ 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: 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: PDB named and default parameters (was Re: [Gimp-developer] The Mark Shuttleworth offer)
Hi, Manish Singh wrote: A PDB revamp is planned. How far along is the planning? I have heard of Rock's libpdb, which I believe he wants to finish for 2.2, but I hadn't heard any concrete plans for the often-mentioned forthcoming PDB re-write. What requirements would the new PDB have? 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: PDB named and default parameters (was Re: [Gimp-developer] The Mark Shuttleworth offer)
On Sat, Mar 20, 2004 at 12:39:23AM -0600, Kevin Myers wrote: It is utterly ridiculous that simply because I voiced concerns about and would like for the ability to have gimp scripts execute properly from the command line under Windows that you accuse me of making the GIMP suck. The suggestions that I offered earlier this evening were only thrown out for consideration, and I didn't try to force those down anyone's throat. All that I asked was that GIMP developers try to give adequate consideration to the needs of Windows based gimp users rather than selecting an implementation that I was worried might have an adverse impact. FWIW, the suggestion was ill-researched. (foo image=bar) is so very very un-Scheme like, which is surprising to hear from someone who has apparently written scripts from scratch. It pays to be versed in the language you're dealing with. Some bias towards Linux and other Unix based systems is completely understandable and acceptable to everyone. We all appreciate the deficiencies of Windows and its poor record of adhering to standards (though there are *many* similar examples in the *nix world as well). We also appreciate that the Linux community is making the biggest share of contributions to the GIMP development effort. What I don't appreciate, is your apparent lack of sympathy towards users who have *no* choice but to run under Windows (for any of numerous reasons) and who simply desire to use the gimp (just as you claim to), and to help enhance it to meet *their* needs, just as you enhance it to meet your own needs under Linux. The gimp is an open source product, and is also supported and developed by Windows users, not just *nix heads. So what gives you the right to presume that only *nix developers can own and control the GIMP (as your comments seem to imply), and to ignore the needs of Windows based users and the feedback and proposals of Windows based contributors? Except there are a number of ways already to workaround the deficiencies of the windows shell. Even if --batch - is broken, you could always save a script out to a file, put it in the scripts dir, and call it from the command line. I'm not saying at all that has happened in this specific instance regarding the issues that I raised earlier this evening and the subsequent discussion. What I am saying Carol, is that some of you appear to be having a rather knee jerk reaction against someone else who is merely trying to help the GIMP better support the operating system that they are using, no different than anyone else who might happen to be using some other OS. If the approach that I suggested won't work or will cause real problems under another OS, that's fine. But what isn't fine is to say in essence we don't care about Windows users and contributors, and we're not going to listen to their input, which is basically what I got out of your reply. It's also better to research your suggestions a little, so that they don't sound completely out there, thereby reinforcing the viewpoint that Windows users are clueless. -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 Sun, Mar 21, 2004 at 09:44:25PM +0100, David Neary wrote: Hi, Manish Singh wrote: A PDB revamp is planned. How far along is the planning? I have heard of Rock's libpdb, which I believe he wants to finish for 2.2, but I hadn't heard any concrete plans for the often-mentioned forthcoming PDB re-write. There hasn't been any real planning, other than planning to do some planning after 2.0 is out. All I was saying is that we haven't forgot about it. What requirements would the new PDB have? Not clear yet. I don't think we should really touch the PDB for 2.2, if we want to do a short release cycle for that. There's a number of issues to be addressed, like GEGL node support, efficiency, UI generation, distributed processing, and macro recording support. -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)
- Original Message - From: Manish Singh [EMAIL PROTECTED] Sent: Sunday, March 21, 2004 2:48 PM snip FWIW, the suggestion was ill-researched. (foo image=bar) is so very very un-Scheme like, which is surprising to hear from someone who has apparently written scripts from scratch. It pays to be versed in the language you're dealing with. I stand appropriately chastised. However, in my defense, I don't write script-fu every day (in fact haven't tried to write any in almost a year now, primarily due to the command line execution issues that I mentioned). Seems like Carol could have simply said that my propsal was too un-scheme-like (as Kelly did), and left it at that. I readily admitted in my opening statements *before* offering the suggestion that it might not be applicable. snip Except there are a number of ways already to workaround the deficiencies of the windows shell. Even if --batch - is broken, you could always save a script out to a file, put it in the scripts dir, and call it from the command line. Yosh, you say that there are a number of ways to work around the Windows shell limitations, and maybe there are, but up to this point nobody proposed one that would work in my scenario. And several folks who are much more knowledgeable about the gimp and script-fu than I am participated in the previous discussion. A number of possible suggestions were made, but all failed for one reason or another. If the approach that you are suggesting now would work, then that's great, but we all simply missed it before, and I guarantee you that Sven and Tor and the other folks who were involved in those prior discussions are not ignorant. It's just that this solution is not particularly obvious or straight-forward or elegant or easy to use. Let's make sure that I'm interpreting your suggestion correctly. Is it as follows: Write a second script that calls my original script, and embed the necessary parameter values in the new script? If that is correct, then yes, I might be able to write a Windows batch file that would take my command line options and write out the necessary line(s) to the new script file, then execute the new script file. And, I appreciate your suggestion. I just wish that this had come up a year ago when I was trying to get this to work. Still, wouldn't you agree that the requirement for this level of workaround under Windows is somewhat undesirable, even given a reasonable level of Linux bias? snip It's also better to research your suggestions a little, so that they don't sound completely out there, thereby reinforcing the viewpoint that Windows users are clueless. Yes, admittedly that is true whenever possible. However, sometimes when you are extremely busy with other tasks and don't have an opportunity to do the desired level of research, it is better to raise a possibly false alarm than it is to let a potential issue go by unnoticed. That seems especially true regarding Windows related issues, since most of the gimp contributors are Linux based, and might accidentally overlook something that could have an adverse effect on Windows usage. Doesn't that seem reasonable? Finally, wouldn't you also agree that it is better to be polite when rejecting someone else's well intentioned suggestions, than to respond in the extremely arrogant and insulting manner of Carol's replies to the newsgroup? s/KAM ___ 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 Sun, Mar 21, 2004 at 03:32:08PM -0600, Kevin Myers wrote: - Original Message - From: Manish Singh [EMAIL PROTECTED] Sent: Sunday, March 21, 2004 2:48 PM Finally, wouldn't you also agree that it is better to be polite when rejecting someone else's well intentioned suggestions, than to respond in the extremely arrogant and insulting manner of Carol's replies to the newsgroup? arrogance? not matching the style of the lead developers on a developers list. not using google and not liking honest answers of what people actually use. using the words insulting and arrogant when describing someones actions who has been constantly involved since 2000 at least. hanging around more when money starts to dribble in? good intentions? i have been working since 2000 to share my good experiences on how to use the gimp, as well as my bad ones. sharing my personal details about how i use my computer to do the job that you want gimp to do only to be accused of not being helpful by you? Kevin: me and the gimp developers are going to show up at your house, eat your food and move your furniture around to suit our needs. please understand -- tis good intentions that allow us to do this and then complain if you dont like what we do. i am sure that Sven and yosh have great ideas about interior design. we will start with your plumbing -- even if it does works, we have been talking about ways it will work for us and our stay much better. you dont even have to thank us for our good intentions. your welcome, carol ___ 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 Sun, Mar 21, 2004 at 03:32:08PM -0600, Kevin Myers wrote: - Original Message - From: Manish Singh [EMAIL PROTECTED] Sent: Sunday, March 21, 2004 2:48 PM snip FWIW, the suggestion was ill-researched. (foo image=bar) is so very very un-Scheme like, which is surprising to hear from someone who has apparently written scripts from scratch. It pays to be versed in the language you're dealing with. I stand appropriately chastised. However, in my defense, I don't write script-fu every day (in fact haven't tried to write any in almost a year now, primarily due to the command line execution issues that I mentioned). Seems like Carol could have simply said that my propsal was too un-scheme-like (as Kelly did), and left it at that. I readily admitted in my opening statements *before* offering the suggestion that it might not be applicable. Would've been better to do some research before posting at all. Except there are a number of ways already to workaround the deficiencies of the windows shell. Even if --batch - is broken, you could always save a script out to a file, put it in the scripts dir, and call it from the command line. Yosh, you say that there are a number of ways to work around the Windows shell limitations, and maybe there are, but up to this point nobody proposed one that would work in my scenario. And several folks who are much more knowledgeable about the gimp and script-fu than I am participated in the previous discussion. A number of possible suggestions were made, but all failed for one reason or another. If the approach that you are suggesting now would work, then that's great, but we all simply missed it before, and I guarantee you that Sven and Tor and the other folks who were involved in those prior discussions are not ignorant. It's just that this solution is not particularly obvious or straight-forward or elegant or easy to use. Let's make sure that I'm interpreting your suggestion correctly. Is it as follows: Write a second script that calls my original script, and embed the necessary parameter values in the new script? If that is correct, then yes, I might be able to write a Windows batch file that would take my command line options and write out the necessary line(s) to the new script file, then execute the new script file. And, I appreciate your suggestion. I just wish that this had come up a year ago when I was trying to get this to work. Still, wouldn't you agree that the requirement for this level of workaround under Windows is somewhat undesirable, even given a reasonable level of Linux bias? Well, first see if gimp --batch - works. If it does, then I don't think that's too much of a big deal to do instead of command line parameters. If it doesn't, then it should be fixed. But yes, you interpreted my suggestion accurately. It's also better to research your suggestions a little, so that they don't sound completely out there, thereby reinforcing the viewpoint that Windows users are clueless. Yes, admittedly that is true whenever possible. However, sometimes when you are extremely busy with other tasks and don't have an opportunity to do the desired level of research, it is better to raise a possibly false alarm than it is to let a potential issue go by unnoticed. That seems especially true regarding Windows related issues, since most of the gimp contributors are Linux based, and might accidentally overlook something that could have an adverse effect on Windows usage. Doesn't that seem reasonable? If it's important to you, you'll do the 10 mins of research and critical thinking needed. You raised your issue about quoting problems, but then you had time to follow up with a completely out there suggestion. So the too busy argument doesn't really fly. It's not like we're planning on making any changes related to this near term, so I don't see the urgency. Finally, wouldn't you also agree that it is better to be polite when rejecting someone else's well intentioned suggestions, than to respond in the extremely arrogant and insulting manner of Carol's replies to the newsgroup? Well, you brought up windows vs. *nix, when the issue is how Scheme works. Perhaps you should've tried to understand the problem better. -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)
If it's important to you, you'll do the 10 mins of research and critical thinking needed. Apparantly you could research this a whole lot faster than I can, which isn't surprising since you work with gimp development almost every day. It would probably take me more than that amount of time just to track down a valid link to the docs for the version of Scheme that the gimp actually uses, much less try to interpret it. You raised your issue about quoting problems, but then you had time to follow up with a completely out there suggestion. So the too busy argument doesn't really fly. You have *no* idea. I've been putting in 18+ hour days for months on end, trying to keep my company above water. I posted these suggestions (and this note) in the down time while I am waiting for my computer to complete other tasks. It's not like we're planning on making any changes related to this near term, so I don't see the urgency. The only urgency is this: I try to respond to things when I see them, when the potential for an issue occurs to me and while the topic is fresh on my mind. If I try to wait until later, then two bad things happen: 1) a lot of issues would get dropped, and more importantly 2) if I bring it up later then folks would claim that it was too late to change things and say why didn't you bring up your concerns sooner when this issue was being discussed? Finally, wouldn't you also agree that it is better to be polite when rejecting someone else's well intentioned suggestions, than to respond in the extremely arrogant and insulting manner of Carol's replies to the newsgroup? Well, you brought up windows vs. *nix, when the issue is how Scheme works. As mentioned, my concern was the command line syntax issue. I don't know all of the Scheme syntax rules. While I was writing my script with Scheme, I found it to be a very arcane language, with very little documentation available, *especially* for the apparantly outdated or non-standard version that the gimp seems to use. So, I thought that I should leave it up to the experts to decide whether my concerns or suggestions were valid, rather than trying to reach those conclusions on my own based on using either the wrong documentation, or misinterpreting the documentation due to being a neophyte with the language, especially considering the limited time that I had available. Finally, *far* too much time and bandwidth has already been wasted on this discussion for all concerned. If folks could have simply explained that my suggestion wouldn't work, rather than making inflammatory statements, then all of this excessive discussion could have been avoided. I've already decided not to respond to Carol's further emails (even though I would like to defend my position) in order to keep from dragging this out further. I now have some idea of your gripes against my input, and hopefully you now have some idea of why my input was provided in the manner that it was. I doubt that anything further can be accomplished. So, how about if we just drop this now, and give all of the other folks on the list a break? s/KAM ___ 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 Sun, Mar 21, 2004 at 05:57:04PM -0600, Kevin Myers wrote: If it's important to you, you'll do the 10 mins of research and critical thinking needed. Apparantly you could research this a whole lot faster than I can, which isn't surprising since you work with gimp development almost every day. It would probably take me more than that amount of time just to track down a valid link to the docs for the version of Scheme that the gimp actually uses, much less try to interpret it. There isn't anything gimp specific. It's straight Scheme. The issue is that you didn't even bother to *try*. Show some respect by doing attempting a little research. Even if you don't get it, that's ok, but you should try. You raised your issue about quoting problems, but then you had time to follow up with a completely out there suggestion. So the too busy argument doesn't really fly. You have *no* idea. I've been putting in 18+ hour days for months on end, trying to keep my company above water. I posted these suggestions (and this note) in the down time while I am waiting for my computer to complete other tasks. Same downtime could've been used for some research. It's not like we're planning on making any changes related to this near term, so I don't see the urgency. The only urgency is this: I try to respond to things when I see them, when the potential for an issue occurs to me and while the topic is fresh on my mind. If I try to wait until later, then two bad things happen: 1) a lot of issues would get dropped, and more importantly 2) if I bring it up later then folks would claim that it was too late to change things and say why didn't you bring up your concerns sooner when this issue was being discussed? You said it was an important issue. If it's really important, you wouldn't forget it. Also, it's clear that we're getting ready to put out a new stable release, after which there will be plenty of architecture dicussions when it'll be more relevant. Finally, wouldn't you also agree that it is better to be polite when rejecting someone else's well intentioned suggestions, than to respond in the extremely arrogant and insulting manner of Carol's replies to the newsgroup? Well, you brought up windows vs. *nix, when the issue is how Scheme works. As mentioned, my concern was the command line syntax issue. I don't know all of the Scheme syntax rules. While I was writing my script with Scheme, I found it to be a very arcane language, with very little documentation available, *especially* for the apparantly outdated or non-standard version that the gimp seems to use. So, I thought that I should leave it up to the experts to decide whether my concerns or suggestions were valid, rather than trying to reach those conclusions on my own based on using either the wrong documentation, or misinterpreting the documentation due to being a neophyte with the language, especially considering the limited time that I had available. But you twisted it into a windows vs. *nix issue, which is what Carol responded to. You really didn't have to do that. A more constructive line of thought is to perhaps enable other language bindings on the command line. Both perl and python work on windows too. Finally, *far* too much time and bandwidth has already been wasted on this discussion for all concerned. If folks could have simply explained that my suggestion wouldn't work, rather than making inflammatory statements, then all of this excessive discussion could have been avoided. I've already decided not to respond to Carol's further emails (even though I would like to defend my position) in order to keep from dragging this out further. I now have some idea of your gripes against my input, and hopefully you now have some idea of why my input was provided in the manner that it was. I doubt that anything further can be accomplished. So, how about if we just drop this now, and give all of the other folks on the list a break? Shouldn't have started with the whole unix bias thing to begin with... But yes, let's drop it. We can discuss language bindings and batch mode in the content of 2.2 and beyond. -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)
anyone else who might happen to be using some other OS. If the approach that I suggested won't work or will cause real problems under another OS, that's fine. But what isn't fine is to say in essence we don't care about Windows users and contributors, and we're not going to listen to their input, which is basically what I got out of your reply. s/KAM - Original Message - From: Carol Spears [EMAIL PROTECTED] To: Kevin Myers [EMAIL PROTECTED]; GIMPDev [EMAIL PROTECTED] Sent: Friday, March 19, 2004 11:17 PM Subject: Re: PDB named and default parameters (was Re: [Gimp-developer] The Mark Shuttleworth offer) On Fri, Mar 19, 2004 at 09:26:23PM -0600, Kevin Myers wrote: Admittedly, the Windows command prompt (not simply Explorer) is less capable than most *nix command shells. However, there are also a very large number of Windows based GIMP users, and one of the requirements of GIMP 2.x is that it should be as usable under Windows as it is on other operating systems. I'm not familiar with R5RS, and you could certainly be right in your opinion regarding that. However, as a Windows GIMP user (and much more rarely a GIMP bug, patch, fix, and enhancement contributor), I want to make sure that there isn't excessive *nix bias that inhibits or ignores usability needs under Windows. TheGIMP only exists for Windows(TM) because at the time, linux and scanners were not working so well together. The GNU/Linux bias is a fact. It is the only reason it exists. For example, in one past case, I wanted to run a simple GIMP script from the Windows command shell, and there wasn't one single person (Sven and everyone else included), who was able to tell me how to arrange the quoting to get the script to run along with the required parameters. That level of disfunctionality is not acceptable, and should be eliminated, even if it means doing something like abandoning (or modifying) certain *nix based standards for the Windows version of the GIMP. To avoid problems like this, linux developers are fairly good at following standards and all sorts of acronyms like api's and rtfm's -- there are more, i cannot remember them. Writing web pages for internet explorer is very limiting and not fun as they have not adhered to browser standards. Are you making TheGIMP suck like this? Obviously though, I do realize the strong need to minimize any such Windows-specific behavior, and that any such differences should receive a great deal of very careful consideration before implementation. In the past however, I feel that the scale may have been tipped slightly too far against Windows on such issues. GNU/Linux is supporting scanners really well now. Perhaps you might be more interested in helping the Image Magick project as they have been running better from the command linue than from the GUI for years. It is available on Windows(TM) also. carol did you read this whole thing? carol ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The Mark Shuttleworth offer
On Fri, Mar 19, 2004 at 08:56:36AM +0100, Henrik Brix Andersen wrote: [stuff deleted] The only thing that struck me as missing was the work involved with porting the plug-ins to the new API, but Raphaël already pointed that out in another reply to this thread. I very much hope that at least this time around, since so much is anyhow changed, the PDB will finally get the face lift and use named parameters instead of positional ones. Regards, Dov Sincerely, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The Mark Shuttleworth offer
Hi Dan, Daniel Rogers wrote: More details have come forward about the Mark Shuttleworth offer. Mark Shuttleworth made up his mind and decided to fund myself and Calvin to work on GEGL and GIMP/GEGL integration. Congratulations! :) Also, I want to prepare a press release about this, and would like some help with that. I can write the content, but those current press releases are so purty, and I'd like any new one to look like them. Can I suggest that you talk to Mark? He has more PR experience than any of us, and I'm sure that he would have some ideas to offer for a press release. 3. begin gimp integration () Time for completion: about a month -- a. replace tile manager with data compatible GeglBufferedImage. This involves modifying the existing gimp-compositing system to use GeglImage, as well as modifying GimpImage and GimpColor to use GeglImage and GeglColor. 4. start adding deep paint () time for completion: about 4-6 months -- a. modify GimpImage and GimpLayer to use a set of GeglOps. -- a. design a new file format (this has already begun), and start converting all the plug ins, core, and paint to use high bit depth (16 bit or float). If you started 3 after 2.2, that would have a 3.0 milestone somewhere around here. Can I check, then, what exactly will get done here? Do we keep a PDB compat layer around so that plug-ins that don't get changed still work, but only on 8 bits per channel? Do we declare teh milestone complete when the core has support internally for floating point, so that only tools get converted first, and we start working on plug-ins afterwards? I think that you're probably underestimating 4 by a bit, particularly since we will want a stable release at this point, which will mean (probably) a 3 month pre-release cycle like the one we've just had. Completion in 6 months is possible (with all plug-ins, I'm not sure), but that would make the 3.0 release next Summer - does that sound reasonable? We could even consider having a quickish stable release after 2.2 with just GeglImage replacing GimpLayer, which would give us a chance to work out any wrinkles in that milestone before we start really relying on it... 6. The big ones () Goal: start adding some long wanted features. a and b probably need to take place at the same time. () time for completion: about 6 months -- a. build the CMYK painting system. This will involve figuring out all the equivalent CMYK and RGB operations, and modifying the GIMP to use CYMK equivalent operations in place of RGB operations. -- b. add color management to the gui. -- c. add layer effects -- d. add layer groups. -- e. add clone layers. Cool - this sounds like a plan. At what stage do we turn plug-ins into nodes and replace the PDB with a node handler? I know that corba's a bad word, but how will plug-ins work after that? Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The Mark Shuttleworth offer
Dave Neary [EMAIL PROTECTED] writes: We could even consider having a quickish stable release after 2.2 with just GeglImage replacing GimpLayer, which would give us a chance to work out any wrinkles in that milestone before we start really relying on it... GeglImage can't replace GimpLayer, it can only replace TileManager. GEGL's scope is not to provide a replacement for GIMP's highlevel object system (GimpImage, GimpDrawable etc) but only for the lowlevel pixel storage buffers and the operations on/between them. ciao, --mitch ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The Mark Shuttleworth offer
Raphaël Quinet wrote: On Thu, 18 Mar 2004 16:38:55 -0800, Daniel Rogers [EMAIL PROTECTED] wrote: More details have come forward about the Mark Shuttleworth offer. Mark Shuttleworth made up his mind and decided to fund myself and Calvin to work on GEGL and GIMP/GEGL integration. Until today, I didn't have any specific details on the offer. You are bringing very good news here. Congratulations! The final thing I want to do here is to seek out what people think about putting a sponsors section on the new webpage, and devoting some space to thank Mark Shuttleworth for this (and hell, our past sponsers too). Do you think that it should be on developers.gimp.org, or www.gimp.org? Maybe both? Anyway, I think that it would be nice to mention our sponsors somewhere. Maybe this should be discussed on the gimp-web list? Probably on the gimp-web list yes. I think it should be on www.gimp.org. Sponsers are important and affect everyone. [...] The ones I really need to run past everyone are 3, 4, 5, and 6 as those involve core gimp and I need to make sure that I am not going to be working on anything that would be outright rejected by the gimp developers. 1 and 2 are gegl territory, and I know I'll accept that work :-) Most of the milestones seem reasonable, but I have some questions about how the GIMP integration would take place, especially regarding the plug-ins. Many of the current plug-ins are making more or less the same assuptions as the core regarding the bit depth of the images, etc. There is a lot of code to be re-written in the plug-ins and I expect them to be broken as soon as the format of the tiles is changed. I also expect that it would be difficult to fix them before some parts of the core become more stable. Well, my plan is to port the plugins to gegl first, then change the tile format. This would mean that, for a time, both old style and new style plugins would work. I also mean a complete review of the plugins, with refactoring of the plugins into a gegl-node + gimp-gui, with a standard set of classes that each plugin is a sub-class of. I suppose that you did not include the plug-ins in your activity planning because that would be too much work for a single programmer (but maybe I am underestimating you? ;-)) So I am wondering how we will be able to coordinate the work and update the plug-ins. Will there be a phase during which there would be a call for volunteers for updating all of the plug-ins once the new interfaces to the core become more mature? Or would it be possible to provide some kind of backwards compatibility so that the transition could be spread over a longer period, with some plug-ins using the new API while some others would still use the old one through a compatibility layer? A transition period is certainly possible. I don't think I will be able to port all the plugins quickly (though I could probably nail 80% of them in a short time, some of them are quite complicated and/or broken). There is also no reason why volunteers can't work on any of this stuff. I am not claiming every piece of this as my territory, only saying I will work on it. That doesn't mean other people can't. And backwards compatability should be possible. There is no reason to make the old plugins stop working (at least for 8 bits per channel, RGB). However the plugins will be more or less broken in that, unless they are ported, they won't work with high bit depths, or different color spaces. What I really meant to say on #4 anyway is that I expect to port most, if not all of the plugins. There is really no other way to do it. I don't believe deep paint will be a useful feature unless at least 95% of our core plugins support it. Let me put a revised #4 4. add deep paint () Goal: to start allowing The GIMP to handle high bit depths. The initial integration should not take long, but I foresee unforeseen problems, so I am setting this estimate high. () time for completion: about 4-6 months -- a. modify GimpImage and GimpLayer to use a set of GeglOps (this is equivlent to adding high bit depth to the core and paint). -- b. design a new file format (this has already begun) -- c. convert all the plug ins to have a class structure and use gegl-ops. -- Dan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The Mark Shuttleworth offer
Kelly Martin wrote: Dave Neary wrote: We could even consider having a quickish stable release after 2.2 with just GeglImage replacing GimpLayer, which would give us a chance to work out any wrinkles in that milestone before we start really relying on it... Unless the code has changed a lot and I haven't noticed it (and looking I see it hasn't), you should be redesigning GimpDrawable (not GimpLayer) to inherit from GeglImage. Actually, yes. Though GimpDrawable, GimpLayer and GeglImage all need to be touched. I'm not sure whether having GimpImage inherit from GeglNode, or contain a member GeglNode, makes more sense. I believe GimpImage is a set of GimpLayers. It might even be able to stay that way. -- Dan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The Mark Shuttleworth offer
Michael Natterer wrote: Dave Neary [EMAIL PROTECTED] writes: We could even consider having a quickish stable release after 2.2 with just GeglImage replacing GimpLayer, which would give us a chance to work out any wrinkles in that milestone before we start really relying on it... GeglImage can't replace GimpLayer, it can only replace TileManager. GEGL's scope is not to provide a replacement for GIMP's highlevel object system (GimpImage, GimpDrawable etc) but only for the lowlevel pixel storage buffers and the operations on/between them. What I mean is that everywhere it makes sense to _delegate_ to gegl structures things should be made to do so. I did misspeak about GimpImage, I know it is not similar to a GeglImage (more like a graph or somesuch). GimpImage and GimpLayer just need to be modified to do their image processing work with GeglNodes. -- Daniel ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The Mark Shuttleworth offer
Daniel Rogers [EMAIL PROTECTED] writes: From: Daniel Rogers [EMAIL PROTECTED] Subject: Re: [Gimp-developer] The Mark Shuttleworth offer To: [EMAIL PROTECTED] Date: Fri, 19 Mar 2004 06:54:34 -0800 Kelly Martin wrote: Dave Neary wrote: We could even consider having a quickish stable release after 2.2 with just GeglImage replacing GimpLayer, which would give us a chance to work out any wrinkles in that milestone before we start really relying on it... Unless the code has changed a lot and I haven't noticed it (and looking I see it hasn't), you should be redesigning GimpDrawable (not GimpLayer) to inherit from GeglImage. Actually, yes. Though GimpDrawable, GimpLayer and GeglImage all need to be touched. Actually no. GimpDrawable is a GimpItem is a GimpObject. It should *have* a GeglImage, not be one. I'm not sure whether having GimpImage inherit from GeglNode, or contain a member GeglNode, makes more sense. I believe GimpImage is a set of GimpLayers. It might even be able to stay that way. It should stat that way I'd say. ciao, --mitch ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The Mark Shuttleworth offer
Michael Natterer wrote: Actually no. GimpDrawable is a GimpItem is a GimpObject. It should *have* a GeglImage, not be one. Damn it. yes. I meant delagation, not inheritance. -- Dan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The Mark Shuttleworth offer
Michael Natterer wrote: Actually no. GimpDrawable is a GimpItem is a GimpObject. It should *have* a GeglImage, not be one. Yes, this is probably correct. Tempbufs should probably also be replaced by GeglImages, and the entire paint core replaced by GeglOp-related operations. As I see it, GimpImage would contain a GeglNode, rather than inherit from it. There would be a contained GeglNode that would represent the current projection; it would be created from the existing layer channel lists. Part of the problem is that GeglNode can represent combinations that the GIMP doesn't support, and adding the UI support for those combinations is (remarkably) nontrivial. Also, there is not a one-to-one correspondence between GeglNodes and GimpLayers (some layers will generate only one GeglNode, others several, especially when layer masks are in use). Relying on decompiling the GeglNode to generate the Layers Channels dialog seems unwise. Kelly ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
PDB named and default parameters (was Re: [Gimp-developer] The Mark Shuttleworth offer)
On Fri, Mar 19, 2004 at 10:50:23AM +0200, [EMAIL PROTECTED] wrote: On Fri, Mar 19, 2004 at 08:56:36AM +0100, Henrik Brix Andersen wrote: [stuff deleted] The only thing that struck me as missing was the work involved with porting the plug-ins to the new API, but Rapha?l already pointed that out in another reply to this thread. I very much hope that at least this time around, since so much is anyhow changed, the PDB will finally get the face lift and use named parameters instead of positional ones. A PDB revamp is planned. While on that subject, I'm wondering what a good way of representing named parameters in scheme and perl would be. Any thoughts? -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)
Manish Singh ([EMAIL PROTECTED]) wrote: On Fri, Mar 19, 2004 at 10:50:23AM +0200, [EMAIL PROTECTED] wrote: On Fri, Mar 19, 2004 at 08:56:36AM +0100, Henrik Brix Andersen wrote: [stuff deleted] The only thing that struck me as missing was the work involved with porting the plug-ins to the new API, but Rapha?l already pointed that out in another reply to this thread. I very much hope that at least this time around, since so much is anyhow changed, the PDB will finally get the face lift and use named parameters instead of positional ones. A PDB revamp is planned. While on that subject, I'm wondering what a good way of representing named parameters in scheme and perl would be. Any thoughts? Hmm, isn't there a perl-way to do named parameters? I bet there is (but I don't know about it). After a quick search on google the following seems to be standard: gimp_perl_foo_bar (-image = image, -drawable = drawable, -radius = 5.5, -size = 300); For scheme we could do something like this: (script-fu-foo-bar '(imageimage) '(drawable drawable) '(radius 5.5) '(size 300)) or (less clutter) (script-fu-foo-bar imageimage drawable drawable radius 5.5 size 300) that having said: I don't have much experience with scheme outside script fu, so there might be a convention out there on how to do named parameters. 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: PDB named and default parameters (was Re: [Gimp-developer] The Mark Shuttleworth offer)
On Sat, Mar 20, 2004 at 12:58:25AM +0100, Simon Budig wrote:
Manish Singh ([EMAIL PROTECTED]) wrote:
On Fri, Mar 19, 2004 at 10:50:23AM +0200, [EMAIL PROTECTED] wrote:
On Fri, Mar 19, 2004 at 08:56:36AM +0100, Henrik Brix Andersen wrote:
[stuff deleted]
The only thing that struck me as missing was the work involved with
porting the plug-ins to the new API, but Rapha?l already pointed that
out in another reply to this thread.
I very much hope that at least this time around, since so much is anyhow
changed, the PDB will finally get the face lift and use named parameters
instead of positional ones.
A PDB revamp is planned.
While on that subject, I'm wondering what a good way of representing
named parameters in scheme and perl would be. Any thoughts?
Hmm, isn't there a perl-way to do named parameters? I bet there is (but
I don't know about it).
After a quick search on google the following seems to be standard:
gimp_perl_foo_bar (-image = image,
-drawable = drawable,
-radius = 5.5,
-size = 300);
Yeah, I thought of that, but I'm not sure how you'd differentiate between
named usage and positional usage.
With both
gimp_perl_foo_bar($image, $drawable, 5.5, 300)
and
gimp_perl_foo_bar(-image = $image, -drawable = $drawable,
-radius = 5.5, -size = 300)
all perl hands the function is a list of values. CGI.pm tries to guess
about this, but it's easily fooled if the actual data string you give it
starts with '-'.
One way to do it would be:
gimp_perl_foo_bar({image = $image, drawable = $drawable,
radius = 5.5, size = 300})
And check if we get a hash reference as our first arg, but that seems
a bit nonobvious.
For scheme we could do something like this:
(script-fu-foo-bar '(imageimage)
'(drawable drawable)
'(radius 5.5)
'(size 300))
or (less clutter)
(script-fu-foo-bar imageimage
drawable drawable
radius 5.5
size 300)
that having said: I don't have much experience with scheme outside
script fu, so there might be a convention out there on how to do named
parameters.
Again there is the problem of differeniating between positional
and named usage.
-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)
Manish Singh ([EMAIL PROTECTED]) wrote: On Sat, Mar 20, 2004 at 12:58:25AM +0100, Simon Budig wrote: For scheme we could do something like this: (script-fu-foo-bar '(imageimage) '(drawable drawable) '(radius 5.5) '(size 300)) or (less clutter) (script-fu-foo-bar imageimage drawable drawable radius 5.5 size 300) that having said: I don't have much experience with scheme outside script fu, so there might be a convention out there on how to do named parameters. Again there is the problem of differeniating between positional and named usage. Ok, thinking some more about it: What about using symbols as parameter identifiers? (script-fu-foo-bar 'imageimage 'drawable drawable 'radius 5.5 'size 300) passing symbols to the PDB doesn't make sense, so this could be used to differentiate. 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: PDB named and default parameters (was Re: [Gimp-developer] The Mark Shuttleworth offer)
On Sat, Mar 20, 2004 at 01:34:02AM +0100, Simon Budig wrote: Manish Singh ([EMAIL PROTECTED]) wrote: On Sat, Mar 20, 2004 at 12:58:25AM +0100, Simon Budig wrote: For scheme we could do something like this: (script-fu-foo-bar '(imageimage) '(drawable drawable) '(radius 5.5) '(size 300)) or (less clutter) (script-fu-foo-bar imageimage drawable drawable radius 5.5 size 300) that having said: I don't have much experience with scheme outside script fu, so there might be a convention out there on how to do named parameters. Again there is the problem of differeniating between positional and named usage. Ok, thinking some more about it: What about using symbols as parameter identifiers? (script-fu-foo-bar 'imageimage 'drawable drawable 'radius 5.5 'size 300) passing symbols to the PDB doesn't make sense, so this could be used to differentiate. That's a good idea. Unless there's some other standard way of handling this in scheme (anyone?) this sounds good to me. -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)
Simon Budig wrote: Ok, thinking some more about it: What about using symbols as parameter identifiers? (script-fu-foo-bar 'imageimage 'drawable drawable 'radius 5.5 'size 300) passing symbols to the PDB doesn't make sense, so this could be used to differentiate. The more Scheme-like approach would be to add a read syntax which instantiates a parameter name type. So, something like (script-fu-f00-bar ::image image) (:: being an arbitrary syntactic marker that I just made for which an appropriate syntax macro has been defined; you can theoretically use anything not already assigned to something else), which is internally expanded to (script-fu-f00-bar #parameter image image) which is then magically converted to however the PDB handles parameter passing by the appropriate Scheme-C glue code. Not only is this more in keeping with how Scheme is generally used, it's conceptually much cleaner because it avoids overloading quoted interned symbols. 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)
For various reasons that I don't know about or don't completely understand, several of the proposals that have already been made may be far superior to what I am about to suggest. In fact, there could easily be some reason why my suggestion is completely unworkable. Never the less, I have worked with other languages where using named items based on the following simple syntax seems to work well, and I'm wondering if it might be a better alternative than some of the other suggestions: (script-fu-foo-bar image=myimage size=300) Some languages allow unquoted parameter strings when the type can be identified based on the parameter name or value and there are no embedded blanks or other delimiters withing the parameter value. Some languages use single quotes instead of double quotes, and some languages allow both. Most languages with syntax along these lines also allow quotes characters to be doubled up in order to represent the occurance of a quote character within the parameter value. Most of you guys are probably already very well aware of syntax like this, so it may not be possible or advisable here for some reason. But I just thought that I'd throw this idea out in case it was being overlooked and might solve any of the other problems that have been discussed. s/KAM - Original Message - From: Kelly Martin [EMAIL PROTECTED] To: Simon Budig [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, March 19, 2004 7:35 PM Subject: Re: PDB named and default parameters (was Re: [Gimp-developer] The Mark Shuttleworth offer) Simon Budig wrote: Ok, thinking some more about it: What about using symbols as parameter identifiers? (script-fu-foo-bar 'imageimage 'drawable drawable 'radius 5.5 'size 300) passing symbols to the PDB doesn't make sense, so this could be used to differentiate. The more Scheme-like approach would be to add a read syntax which instantiates a parameter name type. So, something like (script-fu-f00-bar ::image image) (:: being an arbitrary syntactic marker that I just made for which an appropriate syntax macro has been defined; you can theoretically use anything not already assigned to something else), which is internally expanded to (script-fu-f00-bar #parameter image image) which is then magically converted to however the PDB handles parameter passing by the appropriate Scheme-C glue code. Not only is this more in keeping with how Scheme is generally used, it's conceptually much cleaner because it avoids overloading quoted interned symbols. Kelly ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer ___ 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)
Kevin Myers wrote: (script-fu-foo-bar image=myimage size=300) Defining syntax macros for such a syntax in Scheme is less than straightforward, and is also very un-Scheme-like. 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)
You seem to know what you're talking about Kelly, so I'll have to accept your word that my suggestion is un-Scheme-like. However, please verify one thing regarding your suggestion: How do you handle parameter values with imbedded blanks or other special characters? I am especially concerned about this issue, because previously I have found it almost completely impossible to pass appropriate parameter values to some otherwise very desirable gimp scripts from the Windows command prompt... Thanks, s/KAM - Original Message - From: Kelly Martin [EMAIL PROTECTED] To: Kevin Myers [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, March 19, 2004 8:11 PM Subject: Re: PDB named and default parameters (was Re: [Gimp-developer] The Mark Shuttleworth offer) Kevin Myers wrote: (script-fu-foo-bar image=myimage size=300) Defining syntax macros for such a syntax in Scheme is less than straightforward, and is also very un-Scheme-like. Kelly ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer ___ 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)
Kevin Myers wrote: You seem to know what you're talking about Kelly, so I'll have to accept your word that my suggestion is un-Scheme-like. However, please verify one thing regarding your suggestion: How do you handle parameter values with imbedded blanks or other special characters? (True) Scheme has a quoting mechanism for this issue, which is relatively well defined. It might be tricky to quote those quotes when you're using an inferior command shell (such as Windows Explorer), but this should be considered a fault of those environments -- and is certainly no reason to abandon the R5RS standard. 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)
Hi Kelly, I understand your basic points, but... Admittedly, the Windows command prompt (not simply Explorer) is less capable than most *nix command shells. However, there are also a very large number of Windows based GIMP users, and one of the requirements of GIMP 2.x is that it should be as usable under Windows as it is on other operating systems. I'm not familiar with R5RS, and you could certainly be right in your opinion regarding that. However, as a Windows GIMP user (and much more rarely a GIMP bug, patch, fix, and enhancement contributor), I want to make sure that there isn't excessive *nix bias that inhibits or ignores usability needs under Windows. For example, in one past case, I wanted to run a simple GIMP script from the Windows command shell, and there wasn't one single person (Sven and everyone else included), who was able to tell me how to arrange the quoting to get the script to run along with the required parameters. That level of disfunctionality is not acceptable, and should be eliminated, even if it means doing something like abandoning (or modifying) certain *nix based standards for the Windows version of the GIMP. Obviously though, I do realize the strong need to minimize any such Windows-specific behavior, and that any such differences should receive a great deal of very careful consideration before implementation. In the past however, I feel that the scale may have been tipped slightly too far against Windows on such issues. s/KAM - Original Message - From: Kelly Martin [EMAIL PROTECTED] To: Kevin Myers [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, March 19, 2004 9:07 PM Subject: Re: PDB named and default parameters (was Re: [Gimp-developer] The Mark Shuttleworth offer) Kevin Myers wrote: You seem to know what you're talking about Kelly, so I'll have to accept your word that my suggestion is un-Scheme-like. However, please verify one thing regarding your suggestion: How do you handle parameter values with imbedded blanks or other special characters? (True) Scheme has a quoting mechanism for this issue, which is relatively well defined. It might be tricky to quote those quotes when you're using an inferior command shell (such as Windows Explorer), but this should be considered a fault of those environments -- and is certainly no reason to abandon the R5RS standard. Kelly ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer ___ 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)
Kevin Myers wrote: Hi Kelly, I understand your basic points, but... Admittedly, the Windows command prompt (not simply Explorer) is less capable than most *nix command shells. However, there are also a very large number of Windows based GIMP users, and one of the requirements of GIMP 2.x is that it should be as usable under Windows as it is on other operating systems. I'm not familiar with R5RS, and you could certainly be right in your opinion regarding that. However, as a Windows GIMP user (and much more rarely a GIMP bug, patch, fix, and enhancement contributor), I want to make sure that there isn't excessive *nix bias that inhibits or ignores usability needs under Windows. Windows inhibits its own usability in this respect. It is nearly impossible to get imbedded quotes from the Windows command line. This is a defect in the Windows shell. Getting around it would force us to use some weird character for string quoting, which would be confusing to everyone. In my opinion, the sacrifice is not worth the gain: we should not have to do something Weird and Bizarre to cope with Microsoft's inferior product. 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)
Kelly Martin ([EMAIL PROTECTED]) wrote: Kevin Myers wrote: Admittedly, the Windows command prompt (not simply Explorer) is less capable than most *nix command shells. However, there are also a very large number of Windows based GIMP users, and one of the requirements of GIMP 2.x is that it should be as usable under Windows as it is on other operating systems. Windows inhibits its own usability in this respect. It is nearly impossible to get imbedded quotes from the Windows command line. This is a defect in the Windows shell. Getting around it would force us to use some weird character for string quoting, which would be confusing to everyone. In my opinion, the sacrifice is not worth the gain: we should not have to do something Weird and Bizarre to cope with Microsoft's inferior product. Also please consider, that scripting from the commandline is not the thing the average Windows- (and even Linux-) user needs. If a windows user really needs scripting, I'd recommend to install e.g. a bash. The other option always is to use gimp-1.3 --batch - and pass the commands to execute to stdin. 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: PDB named and default parameters (was Re: [Gimp-developer] The Mark Shuttleworth offer)
Hi Kelly, Though I basically agree with your opinion of the inferior Windows command shell, IMHO that doesn't excuse important GIMP features from being completely inoperable under Windows. Inconvenient is one thing, impossible another. I can appreciate your strong desire to avoid a kludge workaround, but at this point I'm not at all certain that the only possible solutions are quite as bad as your comments would imply. Never the less, I think that we have both probably expressed our opinions adequately on these issues at this point, and may simply have to agree to disagree in some respects, and let other developers and users weigh in to help determine the best approach. I just wanted to help make sure that some concerns from the Windows side of the equation were voiced. I'll back off now and let the discussion resume between yourself and the other gimp gurus. Regards, s/KAM - Original Message - From: Kelly Martin [EMAIL PROTECTED] To: Kevin Myers [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, March 19, 2004 9:48 PM Subject: Re: PDB named and default parameters (was Re: [Gimp-developer] The Mark Shuttleworth offer) Kevin Myers wrote: Hi Kelly, I understand your basic points, but... Admittedly, the Windows command prompt (not simply Explorer) is less capable than most *nix command shells. However, there are also a very large number of Windows based GIMP users, and one of the requirements of GIMP 2.x is that it should be as usable under Windows as it is on other operating systems. I'm not familiar with R5RS, and you could certainly be right in your opinion regarding that. However, as a Windows GIMP user (and much more rarely a GIMP bug, patch, fix, and enhancement contributor), I want to make sure that there isn't excessive *nix bias that inhibits or ignores usability needs under Windows. Windows inhibits its own usability in this respect. It is nearly impossible to get imbedded quotes from the Windows command line. This is a defect in the Windows shell. Getting around it would force us to use some weird character for string quoting, which would be confusing to everyone. In my opinion, the sacrifice is not worth the gain: we should not have to do something Weird and Bizarre to cope with Microsoft's inferior product. Kelly ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer ___ 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)
Simon Budig writes: If a windows user really needs scripting, I'd recommend to install e.g. a bash. True, but doesn't necessarily help. The Win32 process invokation API (CreateProcess()) doesn't use a argument vector like Unix does. It uses a command line. The argv that a C or C+++ main() receives has to be constructed from the command line that the operating system passes to it. (In the Microsoft C library there are exec*()-like functions that take an argument vector, but that argument vector is then joined together into a command line that is actually passed to the CreateProcess() API.) Thus, there are many levels of quoting/unquoting/splicing/whatever going on starting from the command line you type into bash on Cygwin on Windows, ending at the argv passed to main(). If you value your sanity, you shouldn't try to pass a Scheme expression potentially requiring quotes, embedded spaces in arguments, whatever, to a program... The other option always is to use gimp-1.3 --batch - and pass the commands to execute to stdin. Unfortunately, in GIMP 1.2.x, that is explicitly disabled on Win32 in the source. I don't remember the exact reason for this, presumably because some detail in the GLib main loop Win32 implementation that would have prevented it from working anyway. It isn't disabled in the GIMP HEAD (i.e. 2.0preX) sources (and there has been some changes to the GLib main loop now and then), so it might even work. I'll have to check. --tml ___ 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)
, that's fine. But what isn't fine is to say in essence we don't care about Windows users and contributors, and we're not going to listen to their input, which is basically what I got out of your reply. s/KAM - Original Message - From: Carol Spears [EMAIL PROTECTED] To: Kevin Myers [EMAIL PROTECTED]; GIMPDev [EMAIL PROTECTED] Sent: Friday, March 19, 2004 11:17 PM Subject: Re: PDB named and default parameters (was Re: [Gimp-developer] The Mark Shuttleworth offer) On Fri, Mar 19, 2004 at 09:26:23PM -0600, Kevin Myers wrote: Admittedly, the Windows command prompt (not simply Explorer) is less capable than most *nix command shells. However, there are also a very large number of Windows based GIMP users, and one of the requirements of GIMP 2.x is that it should be as usable under Windows as it is on other operating systems. I'm not familiar with R5RS, and you could certainly be right in your opinion regarding that. However, as a Windows GIMP user (and much more rarely a GIMP bug, patch, fix, and enhancement contributor), I want to make sure that there isn't excessive *nix bias that inhibits or ignores usability needs under Windows. TheGIMP only exists for Windows(TM) because at the time, linux and scanners were not working so well together. The GNU/Linux bias is a fact. It is the only reason it exists. For example, in one past case, I wanted to run a simple GIMP script from the Windows command shell, and there wasn't one single person (Sven and everyone else included), who was able to tell me how to arrange the quoting to get the script to run along with the required parameters. That level of disfunctionality is not acceptable, and should be eliminated, even if it means doing something like abandoning (or modifying) certain *nix based standards for the Windows version of the GIMP. To avoid problems like this, linux developers are fairly good at following standards and all sorts of acronyms like api's and rtfm's -- there are more, i cannot remember them. Writing web pages for internet explorer is very limiting and not fun as they have not adhered to browser standards. Are you making TheGIMP suck like this? Obviously though, I do realize the strong need to minimize any such Windows-specific behavior, and that any such differences should receive a great deal of very careful consideration before implementation. In the past however, I feel that the scale may have been tipped slightly too far against Windows on such issues. GNU/Linux is supporting scanners really well now. Perhaps you might be more interested in helping the Image Magick project as they have been running better from the command linue than from the GUI for years. It is available on Windows(TM) also. carol ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] The Mark Shuttleworth offer
So, More details have come forward about the Mark Shuttleworth offer. Mark Shuttleworth made up his mind and decided to fund myself and Calvin to work on GEGL and GIMP/GEGL integration. Until today, I didn't have any specific details on the offer. I am pretty sure the offer essentially the software development bounties described here: http://www.markshuttleworth.com/bounty.html. Mark has said Calvin and I should divide 30,000 dollars between each other and the milestones. We (Calvin and I) are paid when the milestones are delievered with the following conditions (from the Mark's bounty page): Once the code is accepted, to the satisfaction of people identified before you started (for example, the project owners if it involves work extended an existing project), we pay the agreed bounty. Calvin and I have already decided how the money will be divided between each other. What I want to do here, is first announce that Mark is funding GEGL (and thus the GIMP) and second to pass my milestones through the list to make sure they are sane and achieveable. Keep in mind that this milestone list is not a list of work for other people (though other people are free to work on it). It is a list of tasks which I am bound to fufill, contractually, and are things that I _will_ do. I am not obligating anyone to do anything. I am simply confirming that my plan is acceptable, before obligating myself to it. The final thing I want to do here is to seek out what people think about putting a sponsors section on the new webpage, and devoting some space to thank Mark Shuttleworth for this (and hell, our past sponsers too). Also, I want to prepare a press release about this, and would like some help with that. I can write the content, but those current press releases are so purty, and I'd like any new one to look like them. First my milestone list, as I sent to Mark Shuttleworth. Please tell me if it is sane. My time for completion estimates are assuming one programmer working full time. They are also only relevent it that I will use them to help divide up the bounties. The bounties themselves don't have a time limit. You may also make suggestions on how I should divide up the bounties. I'll just divide by the time I think I'll need by default. The end result of these milestones is to add features Mark wants, so I can change the way or order I get to them, but the features achieved should not be changed. The order givin is the order I think I should approach things. The ones I really need to run past everyone are 3, 4, 5, and 6 as those involve core gimp and I need to make sure that I am not going to be working on anything that would be outright rejected by the gimp developers. 1 and 2 are gegl territory, and I know I'll accept that work :-) 1. Finish gegl/image () Goal: gegl/image is the directory that holds the data access libraries. It should contain the abstractions for high-bit-depth and multiple color space manipulations. () Time for completion: about 1-2 months -- a. finish up my nearly completed tile caching code -- b. implement color space classes -- c. write gegl-image can gegl-color 2. clean up nodes () Goal: This will bring gegl all together. Modify the existing node system to handle the new image data types, and get a strong core of basic image processing nodes. Also, build a few image i/o nodes and actually build one or two gegl test programs that actually manipulate image data. One might argue that this step would finish gegl. () Time for completion: 2-3 months -- a. make nodes work with new gegl-image stuff -- b. design processing model that can handle multiple data types and sample models -- c. implement the base set of core filters new filters -- d. implement different bit depth processing functions (prioritizing by what the gimp needs) -- e. make gegl work 3. begin gimp integration () Goal: This puts abstraction in place to actually start handling image high bit depth and color management. () Time for completion: about a month -- a. replace tile manager with data compatible GeglBufferedImage. This involves modifying the existing gimp-compositing system to use GeglImage, as well as modifying GimpImage and GimpColor to use GeglImage and GeglColor. 4. start adding deep paint () Goal: to start allowing The GIMP to handle high bit depths. The initial integration should not take long, but I foresee unforeseen problems, so I am setting this estimate high. () time for completion: about 4-6 months -- a. modify GimpImage and GimpLayer to use a set of GeglOps. -- a. design a new file format (this has already begun), and start converting all the plug ins, core, and paint to use high bit depth (16 bit or float). 6. The big ones () Goal: start adding some long wanted features. a and b probably need to take place at the same time. () time for completion: about 6 months -- a. build the CMYK painting
Re: [Gimp-developer] The Mark Shuttleworth offer
On Thu, 18 Mar 2004 16:38:55 -0800, Daniel Rogers [EMAIL PROTECTED] wrote: More details have come forward about the Mark Shuttleworth offer. Mark Shuttleworth made up his mind and decided to fund myself and Calvin to work on GEGL and GIMP/GEGL integration. Until today, I didn't have any specific details on the offer. You are bringing very good news here. Congratulations! The final thing I want to do here is to seek out what people think about putting a sponsors section on the new webpage, and devoting some space to thank Mark Shuttleworth for this (and hell, our past sponsers too). Do you think that it should be on developers.gimp.org, or www.gimp.org? Maybe both? Anyway, I think that it would be nice to mention our sponsors somewhere. Maybe this should be discussed on the gimp-web list? [...] The ones I really need to run past everyone are 3, 4, 5, and 6 as those involve core gimp and I need to make sure that I am not going to be working on anything that would be outright rejected by the gimp developers. 1 and 2 are gegl territory, and I know I'll accept that work :-) Most of the milestones seem reasonable, but I have some questions about how the GIMP integration would take place, especially regarding the plug-ins. Many of the current plug-ins are making more or less the same assuptions as the core regarding the bit depth of the images, etc. There is a lot of code to be re-written in the plug-ins and I expect them to be broken as soon as the format of the tiles is changed. I also expect that it would be difficult to fix them before some parts of the core become more stable. I suppose that you did not include the plug-ins in your activity planning because that would be too much work for a single programmer (but maybe I am underestimating you? ;-)) So I am wondering how we will be able to coordinate the work and update the plug-ins. Will there be a phase during which there would be a call for volunteers for updating all of the plug-ins once the new interfaces to the core become more mature? Or would it be possible to provide some kind of backwards compatibility so that the transition could be spread over a longer period, with some plug-ins using the new API while some others would still use the old one through a compatibility layer? Anyway, I am glad to see that the offer for sponsoring is becoming more concrete. -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The Mark Shuttleworth offer
Hi, On Fri, 2004-03-19 at 01:38, Daniel Rogers wrote: More details have come forward about the Mark Shuttleworth offer. Mark Shuttleworth made up his mind and decided to fund myself and Calvin to work on GEGL and GIMP/GEGL integration. Until today, I didn't have any specific details on the offer. Congratulations to us! This is good news for the future of GIMP/GEGL. A big thank you to Mark for sponsoring us. The final thing I want to do here is to seek out what people think about putting a sponsors section on the new webpage, and devoting some space to thank Mark Shuttleworth for this (and hell, our past sponsers too). Also, I want to prepare a press release about this, and would like some help with that. I can write the content, but those current press releases are so purty, and I'd like any new one to look like them. If you provide the contents I will be happy to help formatting the press release using LaTeX as I've done with the current press release. First my milestone list, as I sent to Mark Shuttleworth. Please tell me if it is sane. From a quick read through I think the milestones look sane when taking into consideration that one developer will work on them full time. The only thing that struck me as missing was the work involved with porting the plug-ins to the new API, but Raphaël already pointed that out in another reply to this thread. Sincerely, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
