More Shapes/ scribble line/ polygon
Status: Pre-Alpha
Brought to you by:
ghostbust555
Menu
▾
▴
Hi, I am going to add more polygons: parallelogram, diamond, ... .
Seems me I don't understand something but don't know what exactly.
I will be very pleased if you will answer me on following questions regarding to the current implementation of our graphic objects:
1. What is goal of "updateBounds" function ?
2. What is differences between "updateBounds" and "updateModelBounds" ?
3. Our "doPaint" function calls graphics.draw... As I see we are passing some relative coordinates. Relative to what ? To the bounded rectangle ?
I don't understand the flow of "doPaint" function of LineGraphicObject.
Thank you in advance.
1. and 2.
updateBounds() updates the component (GraphicObject) according to its model (Line, Oval, ...) and updateModelBounds() updates the model according to its component.
At the beginning (around r30 I think), there was just one big class GraphicObject and the code to synchronize the models and the components was duplicated and sprinkled in several listeners in GraphicObject, Slide and MainFrame.
I did some refactoring to remove the duplication, break GraphicObject into several subclasses (LineGraphicObject, ...) and use polymorphism; that's when updateBounds() and updateModelBounds() emerged.
But I agree that something doesn't feel quite right with that; what the model is in TextGraphicObject isn't really clear, and I think the component properties should be automatically updated from the model properties.
I intended to do that later, but you can do it if you want: user interaction should result only in calls to updateModelBounds(), and updateBounds() should be called directly only by updateModelBounds().
3.
The overriden paint() in GraphicObject calls doPaint() which is abstract.
Each doPaint() implementation is responsible for drawing its graphic object (line, oval, ...).
TextGraphicObject is a complicated case because it has a composite structure; a bit of refactoring wouldn't hurt there.
The parameter is the normal Graphics object used to draw Swing components, but cast to Graphics2D for more convenience.
Thus, all coordinates are relative to the component.
I'm not sure what you mean about LineGraphicObject: its doPaint() just draws a line with some anti-aliasing...
1. Why during draw rectangle/oval (in function doPaint() of GraphicObject we consider to stroke width in calling graphics.fill... and graphics.draw... ?
Why just not to use (0, 0, component width, component height) ?
We already setStroke() method in graphics object.
2. I removed using in model for rectangle and oval. We can get all parameters which are needed for draw (width and height) from the component itself.
1.
The current offsets optimize the drawing so that the outline doesn't overlap the filled area.
I believe that the visual output would be the same if we used graphics.fill*(0, 0, this.getWidth(), this.getHeight()); to fill a shape.
But the outline must be offset using the stroke width, otherwise part of it would fall outside the clipping area (try it and see what it does).
2.
It makes things simpler for now because we have a raster zoom (as opposed to a vectorial zoom).
But as Kyle pointed out several times, the current zoom system causes a pixelation effect that needs fixing.
Using anti-aliasing is fine for small screens, but I believe it won't be enough for screens with a high resolution.
The zoom problem has been discussed in the forum, and I chose to do a raster zoom because at the time it seemed to be the simplest solution.
But we may have to implement vectorial zoom at some point, and to do that we will probably need model objects whose bounds will differ from the associated components.
Bottom line: it doesn't really matter for now, but we might reintroduce the model objects in the future.
Regarding to graphics.fill, you are right. I tryed to play with diamond and saw the corners are cut off in case of big line weight. So I had to calculate deltas.
Thank you,
Arkady.
I am working on drawing an arrow now.
Would like to use our current implementation of line + draw edge. The problem is, I don't know which vertex is start point and which vertex is end point (I need to know where exactle should I draw edge).
Am I mistaken ? Can you clarify, or advice how to fix, please ?
I think that the lines go from (x1, y1) to (x2, y2), but I'm not sure how it would behave with flipping.
I guess you'll just have to try it.
codistmonk, thank you for the answer. Of course I tried it, it is not always working.
1.
The flipping only affects the X coordinates, which causes the origin/end information to become lost at some point.
Having a flipX() and a flipY() keeps the origin/end information, but the lines are not always properly created.
I think the current resizing system does not allow to do what you want because it is not adapted to lines.
I suggest to fix that and 3011612 at the same time; the goal is to get rid of the flip() method and have only 2 ResizeHandle instances that would move the endpoints.
2.
A while ago you asked about relative coordinates.
I think I see now what you were pointing to.
In LineGraphicObject.doPaint(), the model (Line) coordinates are relative to the slide, and they must be converted into the component coordinates to be drawn.
Since the component coordinates are also relative to the slide, the model has to be translated according to its own bounds, more precisely its minimum x and y values, so that it fits at the top left corner of the component area.
Rectangle and oval didn't need that because of the symmetry of the shapes.
Status: 3 new graphic forms added: diamond, octagon and arrow.
I am stopping work on this task for now and starting to work on bugs. I think it is a good time to stop adding new functionality and it is a good time to take full speed to solve bugs (especially lines issue) + complete empty functionality of buttons (save, print...).
Sorry, I was not logged-in. That is why sender is "nobody" in previous post.