Yeah it was a long day. Started my day with extending help in installation of CalculiX to Balpreet. The errors clearly said it was a path issue. Did some tricks in the Makefile. I just got her two steps ahead in the installation. My bad! 😉
Coming to the implementation of move command, the issues we have been confronting associated with coordinates displayed in the undoStack were shouting to use QGraphicsLineItem. The journey has been like tasting QGraphicsItem, followed by QGraphicsItemgroup and now QGraphicsLineItem for line entity and similarly for other entities too.
Well I have done the switching needed in the classes being inherited wherever it was appropriate. setLine and line methods are coming in action now. The stack still needs correction.
We had an issue related to improper bounding rectangle size for line and ellipse. The bounding rectangle is working decently for line now, not spilling colors. 😀 A tricky implementation for ellipse awaits me.
Whoa! It has struck me why I have been getting local coordinates of all entities , except point, in the undo stack, after they were moved because setPos has not been used for any one of them unlike the point entity. My bad!
The next query is what to be passed onto that position. Say in case of line, starting point or end point or maybe mid point. Well, none of them has worked since the position where line gets painted is not in peace where the mouse clicks were done. Rather it all is still in the local coordinates of the entity.
The position passed into the setPos should be the position of mousePressEvent but they are multiple, one for start point, another for end point. Since this should be only one, mouseMoveEvent comes to rescue I guess. If the line is painted, other entities too, with a live preview, I expect my setPos to cooperate and give me expected results.
I will be tackling with move command and mouseMoveEvent now.
The day started with fixing of issue #50 out of the 4 issues I mentioned yesterday. To have a track of mouse position in the drawing area is helpful to the user. Previously, the eventfilter has been deployed on the entire eCAD window. However, it was required to be working only when mouse was in the drawing area.
Fixed the issue by installing the eventfilter on scene using
And then it was time when everyone present was installing eCAD and reporting issues. Felt more responsibility towards my project. The journey has been awesome till now.
Meanwhile, we continued comprehending the solution to implemenatation of undo/redo for move command. Someone has been pointing me out to use the same logic as it has been done for point entity and I didn’t take much notice considering it to be inappropriate.
From creating a logic to push different number of arguments to the undoStack, I figured the coordinates being local to the entity created, I moved onto understanding the mapToScene() which returns a point’s value in terms of scene coordinates which is required right now. And this would saving so much of redundant efforts we have been thinking that could get involved.
Will be continuing keeping track of various issues and the features in the to do list.
Deleting any entity from the scene kept it in the list that is being iterated when streaming the data to xml file while saving the contents of a scene. Though the entity was not present on the scene, we could find it saved. Exceptions.. 😛
The saving is and must be done corresponding to the entities present at the given time of saving the file. The items() function was the solution. It has been used previously but after moving to QGraphicsItemGroup, it was lost. This function returns the list of items present in a scene. We considered it to be applicable only for QGraphicsItem despite the fact that it is a function of QGraphicsScene which had nothing to do with the type of entities present in the scene. A sigh!
items().contains() made it fixed.
Today we implemented undo/redo for delete operation. Likewise, we proceeded with undo/redo for move operation. Successfully implemented it for point entity. Saving the file also showed the updated coordinates of point. Moving the other entities resulted in inconsistent pushing of positions to the undo stack. Since the other entities need more information to be pushed to the stack, not figured this out yet.
Another issue came by. An item if deleted from the scene got saved because the list being iterated in the writeStream() method keeps a record of all the entities that were once added to the scene. Getting surprises daily. 😉
Also the entities’ properties have been set while one or more of them is selected. The points’ color is changed when selected. A dotted pattern has been implemented showing the selection of other entities accompanied by a change in the color of the points associated with the same entity, say center point for circle, likewise for line and ellipse too.
Since undo/redo form a very essential part of any application, we chose to implement this after the deployment of movement and selection of items. This will avoid the chaos when proceeding with actions like cut, copy and paste. The Qt’s Undo Framework supports undo/redo for all those actions/functions that are inherited from QUndoCommand.
The previous implementation of adding any graphics item to the scene was nowhere close to this. Why had we not inherited QGraphicsItemGroup instead of QGraphicsItem before? Well, moving to this stage made us realize we need to switch to the former and made our implementation quite better and reduced redundancy of a few things too.
Each event like addition, deletion, moving will be having classes of their own where items will be added, deleted and moved respectively. The mousePressEvent dealt with the pushing of the action to the undoStack. We have done with undo/redo associated with addition event today. Will be completing the other two tomorrow.
Feels good to see Ctrl+Z and Ctrl+Shift+Z working. ^_^
Though saving for all entities has been done yesterday but no ids were assigned to any of the saved entities. Continuing it, we have assigned a unique id(duh 😉 ) to each entity in the scene. Pre-increment came into action.
Then we started with selection and moving of entities. It worked decently for point but lost its expected behavior with other entities. Considering line say, it is constructed using two points and a path joining them. If the mouse click was on path say, or any of the one points, voila only the path or the point selected moved and the remaining part of the entity did not bother to accompany. And we laughed!
Learnt another element of Qt namely QGraphicsItemGroup. We created groups for each of the entities. Added the entities’ different parts to this group and then this group was added to the scene just like single QGraphicsItem was done. Got the selection accomplished. The issue of overlapping entities is also solved to an acceptable level according to me but not Gurjot. 😀 We are trying to minimize the bounding rectangle for the entities, considering shape() to be of some convenience.
The save operation has been implemented after the painting of all entities. We are now proceeding to assigning ids, a unique one duh, to each entity.
Since on running eCAD, the mdi area had no document in it and triggering any of the entities brought segmentation fault, the buttons have been disabled until there is no active document in the mdi area.
So I struggled today to correct the implementation of ellipse we had done previously. Deploying QPainterPath for painting now, the ellipse got its axis parallel to the principal coordinate axes, no matter what was the position of clicks with respect to one another. The two cases are shown below though the tilted one has glitches. The angle of the line connecting center and the point giving major radius mattered.
Yeah ellipse is a case of circle or it could be vice-versa but orientation affected the shape of ellipse. For it to be correct, the computation of angle had to be done. Did it but why the ellipse did not rotate? Manipulated the angles: start angle and span angle. Added the angle to both but common sense told it won’t alter anything. For a test, instead of a span of 360 degrees, reduced span angle and yes it was working.
Whoopee! It struck me. The coordinate system’s origin was translated to the center of the ellipse, rotated about an angle == angle between major axis and the original x-axis and then re-translated to its prime position. And it worked! Can be seen in figure above. So unlike the previous implementation, where we did not had any tilted ellipses, that issue was solved today. The minimal bounding rectangle needs to be figured out yet.
Before diving into implementation of MGED, we considered it necessary to understand how MGED works. I have completed basic working as a user on MGED.
Creating shapes, regions, combinations and ray tracing constitute the modeling process. Also learnt how to perform different operations on various objects, namely union, intersection and subtraction. Assigned materials to objects, added internal components to objects, created redefined model for a special case. So now I have clear overview of the working in MGED as a user.
Two of the few models I made:
Next we will be diving into its code.
Continuing my task on Flex/Bison, I could not cope up much with it yet. I have linked the working of flex and bison files, but conversion between formats perplexes me. So much missing from my part.