The Random Argument Input

In the previous implementation, the ordering of arguments mattered. Putting length as second argument after height as the first parameter altered the drawing which was not desired for the user.

Considering the same entity wall, creating few walls like:

wall(l=100,h=30,bx=10,by=10)
wall(h=50,l=120,bx=10,by=40)
wall(bx=20,h=100,by=100,l=60)
,

does not affect the drawing. A vector was created for storing the values of the arguments. The output file I got after splitting removing the delimiters:

wall
l
100
h
30
bx
10
by
10

and similarly for the other two walls, each line is read and the entity name and variable names are compared and pushed to a vector. After one entity is read completely, it is pushed to another vector which stores the complete data of one entity as a single entry. This data is then extracted to obtain the values of variables, passing them to function that writes to DXF file and create the final drawing.

It can be referred here: https://github.com/kamalpreetgrewal/textToDrawing.

It had to be transformed

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.

ellipse

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.

Comme il faut point implementation

After so much grappling with the scene, mouse events and painting, we correctly implemented the point entity in eCAD. Multiple points can be drawn in the scene which can then saved in an xml file and then the file can be loaded as well, resulting in the painting of point entities stored in the file.

Unlike the implementation we did initially, we did not have to make use of any signals to paint multiple point entities in the scene. Coming to the streaming of data, QXmlStreamReader and QXmlStreamWriter has been deployed to open and save an xml file respectively.

And yes, a different class has been improvised to create the graphics scene. Scene was implemented impromptuously previously. We have this innate feeling that now we are proceeding along the right track.

Happy! ^_^

Another trivial step

Yesterday I was able to save only one graphics item i.e. one point only whenever a file was saved. I implemented the saving of all the points in the graphics scene. I thought so! But on opening the file I figured that the number of points saved in the file was equal to number of points in the graphics scene but all of them had the same coordinates.

The coordinates were those of the last point that was painted in the scene. So the thing is I am able to fetch the points in the graphics scene. The update function needs amendment due to which only the coordinates of last point are remembered by the application memory.

I am also able to read the file that was previously saved. The next thing also to be considered is how the data of the graphics item i.e. point for now, would be passed so that the corresponding points are painted in the scene.

In order to implement file handling here, I am deploying class QTextStream. The graphics item in the scene are saved in a QList which is later iterated to stream data to the file. The items() function of QGraphicsScene has been used to create a list of graphics items in the scene.

In my coming posts too, I will be mentioning about various classes and functions of Qt that will be employed in the development.

Cheers!

A busy day!

Ah! Django. The name only always brought fear with it to me. I started with its tutorial today and completed the poll application. It was not that tough as I thought it would be. Besides, it was fun.

And yes, the struggle of 3 days for the implementation of arc using 3 points bore fruits today. 😀

Coming to my own project, I am thinking to keep the repainting issue aside and store the data of one graphics item in a file. Came across QXmlStreamReader and QXmlStreamWriter provided by Qt. These classes save the data in XML format. Data streaming coming to my mind. The items() function of QGraphicsScene is helpful in retrieving the graphics item in a graphics scene. But then on discussion came to know will it work when zooming operations are performed on the graphics scene.

A storm in my head, where will it lead? One question leading to another. So much to explore yet!

No repainting yet!

So the points are stored in vector as I mentioned in my previous post. I am still stuck with repainting of these points in the graphics view. Only the first point painted is visible in the graphics scene.

Earlier, the functionality of repaint was achieved by means of a signal-slot which we discovered not to be befitting for correct implementations subsequently. This signal was emitted every time a point was painted in the scene. But if same approach is followed now as well, the vector continues to have coordinates of one point only with its capacity equal to 2.

Expecting to see such issues in near future as well where we will be confronting the fact that yes, this has to work another way around. Things will be changing. This is all a part of learning.

Also got hands into implementation of arc on mouse clicks with 3 points.

Looking into repainting issue for now!

Beginning with storage

Yesterday, I started with storing the coordinates of various points that are painted in the graphics scene on mouse clicks in vector.

The problem that came up was that there was repetition of a point two times being stored in the vector. The qDebug() (== cout) was implemented in the wrong place. We corrected it.

The next thing that came up wrong was that the vector was not getting appended. Coordinates of one point, the one that was painted at the last, were stored in the vector. The size of the vector remained 1.

On a few modifications, the vector size got incremented every time a new point was plotted. BUT the points that have been painted previously disappeared, only the one painted in the end was visible in the graphics scene. Perhaps, a new scene is generated every time a new point is plotted.

Today, I will be looking into this issue and soon will be able to get it working.

Application Development in Qt

In Qt, basically 5 types of applications can be developed. Depending on your purpose, you choose the one and all the environment for developing the application is provided by the framework. They are namely:

  • Qt Widgets Application
  • <li>Qt Quick Application</li>
    <li>Qt Quick UI Application</li>
    <li>HTML5 Application</li>
    <li>Qt Console Application</li>

In this post, I will be telling you about the first three.

Qt Widgets Application
Widgets form the basic building up entity of a user interface application. Talking in context to any CAD software’s UI, you see a button, a menubar, anything on the user interface, that is a widget. You are able to access the functionalities, the services provided by the software by means of these. These all are widgets.

When you choose to develop this type of application, whatever you do is in C++. This is what the framework provides by default. The thing would be different if you add some QML files in the resources folder of the app. Will be telling you about QML ahead. In this app, we have a UI file by default which is created in design mode of QtCreator. UI files are centred to widget based approach only.

Huh, now coming to the two modes of QtCreator. They are: edit mode and design mode. In edit mode, you do the coding part while in design mode, you have the actual look of the window. You can select any component say a toolbutton or any other component and place it on the window at the place where you want. The associated functionality of the component added in design mode is implemented by means of slots. Well, that is a different concept. Signal-slot mechanism is the soul behind the working of UI apps in Qt. Will be telling some other time.

Just manipulate the code in edit mode and see the components you added in action.

Qt Quick UI Application
This application is developed using the QML(acronym for Qt Modeling Language). It is Javascript based language and centred mainly for user interfaces’ applications. In this type of application, only QML is in action. QML is part of Qt Quick which is a UI-creation kit. You can work in edit mode or design mode here also. Well, working in design mode makes things so easy. The functioning is added in edit mode just like QtWidgets application.

Qt Quick Application
This application is a combination of the previous two. You can have C++ and QML both working in the same project. The rest things are the same as the previous two types of applications.

Well, this was all for someone entirely dummy in application development in Qt, covering some simple things yet important.

And what I see is a book!

Huh! I got my hands a little bit on QML, Qt Meta Language. It is easy to use. Basically it is a language centred for the creation of UIs. The task is to create UI for LCv3 and subsequently for GD CAD.

De novo, I began with exploring demos and examples provided in Qt documentation. Tried a few of them. The very first one making use of concept of states and transitions. It was a simple one. Coming to the UI part, the basic design was prepared and it was not a matter of an hour to see the menu bar and the sub-menus running as a Qt Quick UI application.

Since only the UI, what is visible to the user to be more specific, only bars and buttons was not the concern, the functionality has also to be incorporated for eacch of them. We shifted from Qt Quick UI application to Qt Quick Application. The difference between them being that the latter provides brace for making use of C++ in your application while the former does not. Well, this was all similar. Then reached the functionality part, got stuck at linking QML with C++.

On probing, I was able to use functions created in C++ files of the application in the QML file. Voila! What was needed was exactly the opposite. Never mind, I got something to learn. 😀

Ensuing more exploration and discussions, here I sit just with the root of the application to create UI that would be based on widgets. Things are known but I am not well acquainted to them. I am getting confused at very little things. -_- And what I see is a book that would help me understand things, help me revive them, imprinting in my mind the very basic concepts.

Hits and trials do not take you longer distances. Beginning with foundations of Qt development! Well here I go…

Qt with Coin3D

Well, I do not know how many of you have heard of Qt and Coin3D. In this post, I will be telling you about these and how these two can be used together.

What is Qt?
Qt is a cross-platform application framework that is widely used for developing application software with a graphical user interface (GUI).

Qt can be implemented using following tools:
1.Qt Creator, a cross-platform IDE for C++ and QML. Qt Designer’s GUI layout/design functionality is integrated into this relatively new IDE, although Qt Designer can still be called as a standalone tool.
2.Qmake, a tool that automates the generation of Makefiles for development project across different platforms.

Installation:

  1. Download the source file from http://qt-project.org/downloads according to your system.
  2. Next step is to run the .run file.
  3. First place it in your home directory.
  4. Type in terminal: sudo chmod a+x file-name.run.
  5. Execute ./file-name.run in terminal.
    In my case, I ran qt-opensource-linux-x64-5.2.1.run file and had qt-5.2.1 working on my system.

What is Coin3D?
Check for its installation in my previous post http://kamalpreetgrewal.wordpress.com/2014/03/13/coin3d/.

What is SoQt?
In order to implement Coin3D in Qt, SoQt is required. It acts as glue between Coin3D and Qt.
Type sudo apt-get install libsoqt4-dev in terminal. Now you have SoQt installed.

I had to use Coin3D with Qt. In order to accomplish this, I had to be clear how SoQt and Coin3D work.
The basic working principle is scenegraphs.

What is a scenegraph?
A graphical scene is logically represented using scenegraphs. A scene graph can be defined as collection of nodes in a graph or tree structure. I will be discuusing these in another post.
I created a simple program for cone. The program is:

#include <Inventor/Qt/SoQt.h>

include <Inventor/Qt/viewers/SoQtExaminerViewer.h>

include <Inventor/nodes/SoBaseColor.h>

include <Inventor/nodes/SoCone.h>

include <Inventor/nodes/SoSeparator.h>

int main(int argc, char * argv)
{
// Initializes SoQt library
QWidget
mainwin = SoQt::init(argc, argv, argv[0]);

// Make a dead simple scene graph by using the Coin library.
SoSeparator * root = new SoSeparator;
root-&gt;ref();

SoBaseColor * col = new SoBaseColor;
col-&gt;rgb = SbColor(2, 3, 0);
root-&gt;addChild(col);

root-&gt;addChild(new SoCone);

// Use one of the convenient SoQt viewer classes.
SoQtExaminerViewer * eviewer = new SoQtExaminerViewer(mainwin);
eviewer-&gt;setSceneGraph(root);
eviewer-&gt;show();

// Pop up the main window.
SoQt::show(mainwin);
// Loop until exit.
SoQt::mainLoop();

// Clean up resources.
delete eviewer;
root-&gt;unref();
SoQt::done();

return 0;

}

The next step is open terminal and go to directory where you saved the file.
Follow these steps in terminal:

  1. qmake -project : generates cone.pro file
  2. qmake : generates Makefile
  3. make : In case of some errors regarding SoQt missing (or something similar), open Makefile. Go to LIBS. Append this line with -lSoQt -lCoin and you are done. Again run make.
  4. ./cone

An Examiner Viewer window will show a cone. That’s it. You used Coin3D with Qt. Yeah, was not tough so far. 😀 In case of any queries, do comment.