[Gimp-developer] Re: Constraints, Path tool
From: Simon Budig [EMAIL PROTECTED] I don't see how this could be useful in an image manipulation context. If implemented for a program primarily intended for vector stuff (Skencil, Sodipodi) this might be very helpful, but in GIMP the primary goal for now is to create pixel based images - which is notoriously bad for above mentioned technical drawings. OK. The p54-freeman-benson.pdf paper has an example on musical notations (second page). GIMP could have similar plugins providing that kind of editor and renderings. It doesn't need to be limited to musical notations but text could work as well. The constraints system would make it easier to make automatically room for the letters and icons when they are inserted. Note that Cinepaint has added a vector data layer. That layer could be saved within the image file and plugins could use the vector data layer as input. If such layer is implemented in GIMP, it opens many new possibilities: E.g., I could have a constraint based tool for arranging photos on a virtual desktop. The photos on the desk would not overlap. For the photo which I grab and drag, the constraint system would make a room on the desk by moving other images. In this case the vector layer would contain image objects (polygons). Of course, even simplest tool such as unirectangle selection tool would benefit: in the tool, when mouse button is pressed first time, I would create a rectangular polygon with the grabbed vertex constrained to the pointer and all other vertexes constrained to the grabbed vertex. In the crop tool, where the polygon stays active for longer time, grabbing would change the constraints depending on what is grabbed and moved. BTW, the multitrack audio editor Ardour includes Cassowary constraints library. It looks like it is not used at all, but the plans and some tests were done at 2003 Jan/Feb for constraining audio pieces during some editing tasks. The discussions were archived at sourceforge but I could not find them anymore as Ardour moved to ardour.org. I did read the mails from my private archives. I have mentioned Qoca but Cassowary seems to work as well. Regards, Juhana ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Constraints, Path tool
From: Simon Budig [EMAIL PROTECTED] Could you read the sketchpad.pdf and check how it differs from how the path tool is handled? It would be your task to explain to explain to me what you want. As I said earlier I am quite satisfied with the way it works now. No. It is better that some of you too will read about the topic. The provided sketchpad paper has a good framework, and I would like to know if that gives any ideas to anyone of you. My posting was not meant for unwilling persons like you, but for anyone who could read the papers and fit the strong ideas given in the papers to GIMP. Also, the path tool deals with bezier curves, the paper does not. The path tool handles polygonal line segments, the paper does not (only single straight lines). Please don't read too narrow-mindedly. The Sketchpad has been used to construct more complex geometries than a single stright line. Read the whole paper, don't stop to first figure. The framework in Sketchpad is the most important part (not the curves): the constraints and the object oriented data management. It can be used for any new objects, including Bezier curves. Last I ckecked, your framework in Path Tool was not used in the rectangle selection tool nor in crop tool. Can you put your framework to a form in which I may use it to code new unirectangle and new crop tool for us? We need not to check new frameworks if existing ones are good enough; and they are good enough if they can be used to program new tools. For circles a significant different way to handle them has become quite standard for vector applications. And I'd prefer to match the handling in other recent programs than a paper from 1963. Qoca constraints solver papers have been published quite recently (200?). The papers with good intro sections has been published at 199?. What papers you have been reading? Does your framework in Path Tool implement any constraints based manipulations? Just read the papers and check if they raise up any ideas. Regards, Juhana ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Constraints, Path tool
Hi, Juhana Sadeharju [EMAIL PROTECTED] writes: Last I ckecked, your framework in Path Tool was not used in the rectangle selection tool nor in crop tool. Can you put your framework to a form in which I may use it to code new unirectangle and new crop tool for us? We need not to check new frameworks if existing ones are good enough; and they are good enough if they can be used to program new tools. The fact that the new vectors architecture isn't more widely used yet doesn't mean that it can't be put to more use. The vectors framework in the GIMP core is very new and IMO it fits our needs. You haven't explained yet what exactly you don't like about it. If you actually tried to use it and failed then your complaints would make sense, but as it stands you are suggesting to replace a perfectly working framework with lots of potential by some vaporware. And so far you failed to give any reason why that should happen. The papers you are pointing us at might be worth reading and they could certainly inspire us for new ideas. But I don't see why you keep bashing on the current vectors framework since obviosuly you didn't even look at it yet. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Constraints, Path tool
[while this is a rant, there is useful content in this mail] Juhana Sadeharju ([EMAIL PROTECTED]) wrote: From:Sven Neumann [EMAIL PROTECTED] bashing on the current vectors framework since obviosuly you didn't even look at it yet. The Path Tool framework was just mentioned to me. Then I quickly re-checked out those papers if somebody would actually want read them now. Only a good intention. But I got flamed. I have not bashed the current vector framework because I have not seen it yet. May I quote yourself? The selection tool vector drawing and the crop tool vector drawing are not visible in other views of the same image because the framework is kludge. [...] missing completely the point in this kludge code Calling something a kludge *is* bashing, especially when you did not even bother to look at it. As I wrote earlier, I thought quite a lot about that stuff to get it right. I rewrote it two times basically from scratch. I worked on this for a really long time. Now you come along, tell me that Gimps framework is a kludge and you did not even look at it, but suggest me to read dozends of pages to realize what is a cludge with my stuff. And you expect me to take you seriously? What I want is written very clearly in the intro sections of those mentioned papers (published at 199?; in constraints/ dir at my site). If you don't even have an idea of what I'm talking about, how ever I could go in to details? It would be a good idea to explain the basic ideas in a comprehensible way. The previous poster confused at level of a basic stright line vs. a Bezier curve; missing completely the point in this kludge code vs. constraints code discussion (started in gimp-user). The original post I replied to (on gimp-user) does not contain the word constraint. In your second mail you also do not explain what you mean by constraint. In your first mail you wrote: What we need is a good old vertex/edge/polygon framework. We *have* a vertex/edge/polygon framework, and the edges even can be bezier segments, which is far more suitable for defining pretty common curved shapes. But you called this a kludge. And now you complain that I get pissy? No need to ask me to repeat. I have mailed on constraints in several mails within last months, but nobody informed me that constraints are already implemented in GIMP. I did not find them in a recent CVS code (taken february or march). Sure I will check how the Path Tool stuff could be used in implementing the new tools. It just is not the vectors I want, but the powerful constraints framework. After installing the unirectangle geometry I don't want manipulate it at vector value level. Now unirectangle is simple stuff, but things gets more complicated if I need more complex tools. Some extra power would make things simpler. Read the papers for what I mean. Please explain what a unirectangle is. A google search for this word turned up exactly one mail from you - where you don't explain it. After looking at sketchpad.pdf again I understand that the constraints you are talking about seem to be relations between vector objects (this rectangle has the same height as the length of this line, these polygonal edges lie evenly spaced on a circle etc. I believe hints in fonts are a similiar idea. While this certainly could be useful for technical/mathematical drawings I don't see how this could be useful in an image manipulation context. If implemented for a program primarily intended for vector stuff (Skencil, Sodipodi) this might be very helpful, but in GIMP the primary goal for now is to create pixel based images - which is notoriously bad for above mentioned technical drawings. So, unless you can bring up some compelling use cases for constraints in an image manipulation context, I don't believe that they will be implemented in the near future. On the other and I am fully aware, that the vectors infrastructure in the GIMP could be more widely integrated. It should be fairly easy to implement rectanges and ellipses as vector objects. It definitely would be cool to have them used for Crop and the selection tools, but we need to iron out the usage scenario for adding/intersecting/substracting selections in connection with the ability to manipulate the vector shapes. I am willing to continue this discussion, but not if you continue to call my stuff kludge. And I don't want to read scientific publications to guess what your ideas are. You apparently are deeply into that stuff, so it should be fairly easy to you to bring up examples. Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
