User:H1manshu/GSoC2022/Log

From BRL-CAD
< User:H1manshu
Revision as of 08:06, 13 July 2022 by H1manshu (talk | contribs) (Updated 12 July)

Dev Log

(newest first)

  • 12 July:
    • I took a day off and will continue tomorrow.
  • 11 July:
    • I added a new pull request where I fixed the issue of switching tabs in which it doesn't show the properties of the primitives in Properties Dock by selecting the first approach that I have mentioned previously instead of taking the second one.
  • 10 July:
    • I found two solutions to fix the properties dock issue:
      • Shift TypeSpecificProperties * current and BRLCAD::Object * object instead of keeping them static. Initialize them to nullptr and allocate the memory only when the object is selected so that it will store the value even if the object is switched or a document is switched where there is another object in switched document which is already selected before.
      • Create another signal-slot connection where the document if switched then it will emit a signal to Properties::bindObject(const int objectId) slot so that it will show the values of the primitive in properties dock but every time the document switched then the signal will always emit to slot and fetch & assign will go from the database.
  • 9 July:
    • I started debugging upon a issue and found the root cause of this issue.
    • The root cause of the problem is static TypeSpecificProperties * current = nullptr;. Since current is static, it retains the values of the primitive, but if the document is switched, then it cannot display the properties because current still retains the values of the previous document object instead of the current one.
    • Seems like it only works when the object is selected then the signal calls void Properties::bindObject(const int objectId) {} slot and it works only for the same document where many objects can be switched but not if the document is switched.
  • 8 July:
  • 7 July:
    • I and my mentor Daniel discussed a bug in Google Meet where I addressed a issue.
    • I was suggested some points by my mentor on how to fix the issue where the memory gets piled up even if the document was closed and it only gets released when the application got closed.
    • Also we discussed how to detect if a document is modified or not which will help to detect if there are unsaved changes in a file then it can prompt to save the file and then close the application.
  • 6 July:
    • Started debugging to see how activeDocumentId is playing a part as a key for std::unordered_map<int, Document*> documents; and found out that all the tabs memory only gets deleted after the application is closed. So I am thinking to delete the tab and free the memory only when the user closes the tab instead of consuming more memory.
    • activeDocumentId and documentsCount needs to be sync because if we want to close a tab then it can delete any other tab is opened and can free the memory which is dangerous and needs to be handled.
  • 4-5 July:
    • Done nothing because of my entrance examination.
  • 3 July:
    • I have some things to do before I start implementing save feature:
      • Free memory as soon as I close the tab instead of eating up all memory even if the tabs are already closed through GUI. The current scenario of this thing is that in unordered_map all documents are destroyed after the application is closed. Instead of this, we should free memory as soon as the tab gets closed. Currently, I don't how the data is being saved in the database. By far I only came to know how a file is currently saving the data:
bool MainWindow::saveFile(const QString& filePath) {
    return documents[activeDocumentId]->getDatabase()->Save(filePath.toUtf8().data());
}
      • I need to know how getDatabase()->Save(filePath.toUtf8().data()) is actually being saved in a database. I have found Database.h and MemoryDatabase.h and need to see how this working on to save a file. Without knowing how these are working, I can't know what to do for unsaved changes. I think to implement isModified() to check if the document have any unsaved changes like this:
bool MainWindow::saveFile(const QString& filePath) {
    if (!isModified()) {
        return false;
    }
    return documents[activeDocumentId]->getDatabase()->Save(filePath.toUtf8().data());
}
  • 1-2 July:
    • I looked into MainWindow.cpp and understood how saveFileDefaultPath(), saveAsFileDialog() & saveFile() are working to save a .g file.
    • I found that in saveFile(), I have to implement a feature where it can check if there are unsaved changes then it should save it otherwise it should return false.
    • Also found a bug that even if there are no changes to the file, the save function is working to save the file. This should not work unless there is a change in a file.

June

  • 30 June:
    • I started working on implementing closeEvent() where it will check if an unsaved work is saved or not.
  • 27-29 June:
    • My mid-semester exams are going on.
  • 26 June:
    • Done nothing because I am preparing for my exam.
  • 25 June:
    • Done nothing because my exam is coming on 27th June which will continue till 29th June.
  • 24 June:
    • I started working on the toggle feature for Grid Action. This feature will work simultaneously with tool button Grid.
  • 23 June:
    • I pushed a new commit where I added icon for Save As action and added rest icons for toolbuttons.
  • 22 June:
    • I found some bugs during testing that MainWindow::tabCloseRequested(const int i) and MainWindow::closeButtonPressed() are not handled if a document is open and there is unsaved changes. And closing the tab should open a dialog and ask to save it. Save goes for closeButtonPressed() if the whole application is going to be closed then it should check if there any unsaved changes that are not saved yet.
  • 21 June:
    • I learned about QFile and QDir which will help in implementing closeEvent as this is not yet implemented in arbalest.
  • 20 June:
  • 19 June:
    • I created two new commits where I selected a suitable color for toolbutton that will fit both light and dark themes.
  • 18 June:
    • I started learning event propagation and event filters where I came to know about QCoreApplication::notify. I tested QPushButton class and QLineEdit by taking one parent class and child class to see event propagation.
  • 17 June:
    • Learnt about events which will help me to better understand the events that are in arbalest. I learned mouse events, paint events, context menu events, etc.
  • 16 June:
    • I pushed a new commit to pr where I removed icons from QToolButton because setDefaultAction() is inheriting icons from QAction.
    • Added suitable colors for the menu bar and toolbar icons to suit both light and dark themes.
    • Fixed merge conflict.
  • 15 June:
    • Took a day off because I was feeling exhausted.
  • 14 June:
    • I found that the icon becomes green due to the icon that I had set for QAction in toogleGridAct. So when I click on the tool button of toggleGrid, it swaps with the color that had been set for icon in QAction.
    • I commented out setIcon of QToolButton for toggleGrid and ran the program. I found that the the setIcon for QAction is acting default for QToolButton too. The icon for QAction is already there for QToolButton too which means setDefaultAction is playing a part here.
  • 13 June:
    • I created a new pull request to add toggle feature for Grid.
  • 12 June:
    • Started working upon to add a toggle feature for Grid. This feature will be added in QToolButton for Grid.
  • 9-11 June:
    • I learnt memory management and signals & slots in Qt. Also I took a tour of Qt Widgets.
  • 8 June:
    • I created a new pull request where I added icons for menu items and icon color for both light & dark theme.
  • 7 June:
    • I created a new commit to remove the absolute color of hover for QToolButton. Also, I am currently testing out which color will be best suitable for icons in menu items for both light and dark themes.
  • 6 June:
    • I created a pull request to remove border and add padding. I also added hover background-color to QToolButton
  • 5 June:
    • Done nothing as I came back from a different state of my country where I went for to appear the exam.
  • 4 June:
    • Done nothing as today is my entrance exam.
  • 3 June:
    • Done nothing as I am preparing for my upcoming entrance exam.
  • 2 June:
    • I wrongly applied $Color-IconView for QToolButton. It should be different colors for different QToolButton. I created a new commit and pushed the changes for the same.
  • 1 June:
    • I created a pull request to remove QPushButton and add QToolButton so that the QAction objects for file, view, and ray trace can be used as one single unit. And I mentioned this pull request with an issue

26 - 30 May

  • 30 May:
    • Discussed with mentor for what to choose between QToolButton and QPushButton. Also I got to know that QAction can be assigned to QToolButton which will be better because once object of QAction is created then we can assign it to QToolButton.
  • 29 May:
    • Started working on the issue where I saw QAction and QPushButton have been defined for the same New and similarly I found more like that.
  • 28 May:
    • Done nothing as I couldn't get time because I went to see my father.
  • 27 May:
    • Learnt about arbalest QMainWindow but only by far, I covered Menu bar. I found all the QAction * buttons are missing icons but code was already written to set icons for each QPushButton *. So I opened an issue. I will work on it tomorrow.
    • I also created a pull request for minor changes to main.cpp of arbalest.
    • I will cover Central Widget of arbalest which is the most important of this project because this is the area where the mouse support feature will be added. I will try to cover it from tomorrow during this community bonding period. Here an outline is taken from Qt docs of QMainWindow just for reference:
      QMainWindow Outline
  • 26 May
    • Created workspace where I built brlcad and rt-cubed. Set path for Qt 5.14.2 so that arbalest could be run to check if it is running without errors.