Difference between revisions of "User:H1manshu/GSoC2022/Log"
From BRL-CAD
(Updated 28-31 Aug) |
(Updated 5 Sept) |
||
Line 2: | Line 2: | ||
(newest first) | (newest first) | ||
+ | ===September=== | ||
+ | * '''5 Sept''': | ||
+ | ** Implemented a check for unique object names through '''Get()'''. | ||
===August=== | ===August=== | ||
* '''28 - 31 Aug''': | * '''28 - 31 Aug''': | ||
Line 9: | Line 12: | ||
** Still need to fix [https://github.com/BRL-CAD/arbalest/issues/35 35] | ** Still need to fix [https://github.com/BRL-CAD/arbalest/issues/35 35] | ||
* '''21 - 26 Aug''': | * '''21 - 26 Aug''': | ||
− | ** Removed return type'''MemoryDatabase''' object and added '''ConstDatabase''' object for '''getDatabase()'''. | + | ** Removed return type '''MemoryDatabase''' object and added '''ConstDatabase''' object for '''getDatabase()'''. |
** Removed color scheme of message box. | ** Removed color scheme of message box. | ||
** Shifted '''getBRLCADObject()''' inside '''Document''' class. | ** Shifted '''getBRLCADObject()''' inside '''Document''' class. |
Revision as of 08:13, 6 September 2022
Contents
Dev Log
(newest first)
September
- 5 Sept:
- Implemented a check for unique object names through Get().
August
- 28 - 31 Aug:
- 27 Aug:
- 21 - 26 Aug:
- 18 - 20 Aug:
- Overloaded Get() of ConstDatabase class which leads to more constness errors in the program.
- 17 Aug:
- Found two overloads for BRLCAD::ConstDatabase::Get() while debugging getDatabase().
- Used Object* ConstDatabase::Get(const char* objectName) and it works without throwing any other errors.
- 16 Aug:
- Removed header color of the dialog box.
- Add *cancel instead of cancel.
- 14 - 15 Aug:
- Discussed with mentor about how to start with adding mouse feature to the arbalest.
- Refactored maybeSave() so that it can accept documentId and cancel parameter to work both for tabCloseRequested and closeEvent().
- 11 - 13 Aug:
- Not feeling the vibe to do something. Will start from 14th.
- 7 - 10 Aug:
- 6 Aug:
- 3 - 5 Aug:
- Completed the ongoing PR.
- Added new saveFileId() so that it can save document respective to document index.
- Tested out the PR in all various ways so that there is no bug left behind.
- 1 - 2 Aug:
- I added Add and Save for class Document but still there are some errors like many primitives functions are not accessible and Load function of class Database needs to be overridden in class Document.
July
- 31 July:
- Pushed a new PR to add apache license 2.0 to aboutwindow.cpp
- 27 - 30 July:
- Created an issue where the ray-trace function works even if there is no primitive present in the document.
- Added ConstDatabase and removed some of the errors reported by the compiler but still there are errors that needs attention.
- 26 July:
- Pushed a commit where I removed function overloading for Save and added Cancel button.
- 24 July:
- Taking a day off since I am having a fever.
- 23 July:
- Pushed a new commit where I added two new functions which will help maybeSave().
- 22 July:
- Done nothing since I have to be ready for the project presentation for university.
- 20 - 21 July:
- I started implementing what I discussed with my mentor and restructured the whole maybeSave().
- 19 July:
- Discussed with mentor about how to modify maybeSave() where instead of keeping two warning message, it should be one. Also we discussed how we can modify the database using ConstDatabase.
- 18 July:
- Seems like maybeSave() is super lengthy and I can't find how to check if the database has been modified.
- 17 July:
- Added QVector<QPair<int, QString>> for storing documentId with respective to file name instead of storing them separately.
- 16 July:
- I completed maybeSave() and now I can start looking at isModified().
- 15 July:
- I write some code where it will check if there are multiple files then it will prompt for saving it if unsaved other or if there is one and only file then it will prompt with the file name.
- Added new commit where I partially added some code for maybeSave().
- 14 July:
- I pushed a new commit where I removed QAction::triggered and added QAction::toggled signal since grid action is suitable for toggle only.
- Also I added some code for maybeSave() and thought to check each and every document that is opened and not saved should prompt to save the changes. But haven't looked into database yet.
- 13 July:
- I started working upon restructuring the way the closeEvent() will function which will help in saving the unsaved changes to the document.
- 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.
- I found two solutions to fix the properties dock issue:
- 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:
- I created a new pull request where I fixed the previous discussed issue.
- 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:
- I have some things to do before I start implementing save feature:
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
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:
- 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.