Saving the window geometry alone is not sufficient to save the state of the Program View dock widget. The state of the main window also needed to be saved to preserve the settings of the tool bars and dock widgets, including where they are docked or floating (undocked), their sizes, and whether they are turned on or off. This window state was added to the save and restore settings routines of the main window, which were given the settings name windowState.
A dock widget can also be turned off by clicking its close button on its upper-right corner. To turn it back on, there is a context (right-click) menu that can be accessed by clicking on the unused part of the menu bar or tool bar area. A dock widget can be undocked (to make it floating) by dragging the dock widget title bar away from the main windows. Tool bars can also be undocked.
When I discovered this context menu when noticing that there was an empty tool bar beside the main tool bar that should not have been there. Besides the Program View dock widget, this context menu also showed a blank tool bar and toolBar. The blank tool bar was actually the main tool bar and it was blank because the main tool bar was never given a title (the windowTitle property).
These issues were corrected by assigned the main tool the title Main Tool Bar and the extra tool bar was removed (which must have been added by default when the Main Window GUI class was created and a new tool bar was inadvertently created to hold the tool bar actions).
[commit 9d3c4a9404]
Monday, March 11, 2013
Sunday, March 10, 2013
Program View Line Numbers – Custom Item Delegates
It will be very helpful during testing if the program view displayed line numbers like the edit box. This was accomplished with what Qt calls a custom item delegate. An item delegate is responsible for drawing the items in a widget and widgets have a default delegate.
A new ProgramLineDelegate class was created with the QItemDelegate class as its base. Since the program list view is read-only, the only function that needs to be reimplemented in this new class is the paint() function, which has arguments to the painter (used for drawing to the screen), the current style option (which contains information about the view item like its bounding rectangle), and an index of the item to paint.
To start simple, the line number is obtained from the row of the index and the text of the line is obtained from the model of the index (currently the QStringListModel setup to hold the program lines), which is used to get the string of the item that needs to be displayed. These two items are formatted using the string "%1: %2" to put the line number followed by a colon and the string of the program line. This string is then drawn to the screen using the painter's drawText() function.
This is crude, but was a proof of concept (this is my first time using delegates). This will be cleaned up next by drawing the line number separately in its own rectangle with a different background color. It will also need to determine the width of this rectangle based on the maximum line number like with the edit box.
[commit 941b1f8e75]
A new ProgramLineDelegate class was created with the QItemDelegate class as its base. Since the program list view is read-only, the only function that needs to be reimplemented in this new class is the paint() function, which has arguments to the painter (used for drawing to the screen), the current style option (which contains information about the view item like its bounding rectangle), and an index of the item to paint.
To start simple, the line number is obtained from the row of the index and the text of the line is obtained from the model of the index (currently the QStringListModel setup to hold the program lines), which is used to get the string of the item that needs to be displayed. These two items are formatted using the string "%1: %2" to put the line number followed by a colon and the string of the program line. This string is then drawn to the screen using the painter's drawText() function.
This is crude, but was a proof of concept (this is my first time using delegates). This will be cleaned up next by drawing the line number separately in its own rectangle with a different background color. It will also need to determine the width of this rectangle based on the maximum line number like with the edit box.
[commit 941b1f8e75]
Loading File and New File Issues
While testing with the new program view, when doing a File/New, the last line in the document remained in the program and the line was set modified. With New, the entire program should be cleared. Further testing revealed additional problems when loading a new file replacing the current file where the lines in the old file were not being removed before the new file's lines were inserted.
Some additional checks were needed to properly handle these situations, which occur when the document is empty. If the cursor move failed (which occurs when the file is emptied either with a New or before a new file is loaded), if the change indicates one character was added (occurs with the first of two change signals), then a New operation is occurring. The modified line variable is set to -2 to indicate that a New is in progress so that when the second signal is processed, the code knows if it is due to a New and not a file load. Otherwise, if the current line count is zero (the document was empty before the change), then this is the first signal of a file load and should be ignored.
When the document is empty and neither of these conditions exist, then all of the document contents were removed, either because a new file is being loaded, a New was selected, or all of the characters were deleted (for example, with repeated deletes or Selected All and Delete). For the first two situations, all of the lines of the program should be reported as deleted, but for the third, the last line should remain and be set as the modified line. The load file conditional occurs when the cursor move failed and the New previously set the modified line to -2. For these conditions, the net line count is set to the number of lines that were in the document, the new line count is set 0 and the change at the beginning of the line flag is set because it is not set when the document is empty.
At the end of the document change routine where the modified line is set to the current cursor line (the end of the change), it needs to instead be set to -1 if it currently set to a -2 from a New operation, so that the first (and only) line in the document after a New operation is not marked as modified.
One other minor problem was also discovered when an empty file is loaded and the document was previously not empty. The window modified flag was set (shown with an asterisk after the file name in the window title bar). I'm not sure why this occurs, but it was corrected by clearing the window modified flag after a program is loaded and the document is set. Reseting the edit box document's modified flag was not sufficient.
Finally, it was noticed that the program view list widget was grabbing focus when a new file was loaded or New was selected as evidenced by the edit box cursor disappearing and the focus could be seen be the light blue focus indicator around the widget. This list view widget was prevented from grabber focus by setting its focusPolicy property to NoFocus.
[commit 65bd6a9233]
Some additional checks were needed to properly handle these situations, which occur when the document is empty. If the cursor move failed (which occurs when the file is emptied either with a New or before a new file is loaded), if the change indicates one character was added (occurs with the first of two change signals), then a New operation is occurring. The modified line variable is set to -2 to indicate that a New is in progress so that when the second signal is processed, the code knows if it is due to a New and not a file load. Otherwise, if the current line count is zero (the document was empty before the change), then this is the first signal of a file load and should be ignored.
When the document is empty and neither of these conditions exist, then all of the document contents were removed, either because a new file is being loaded, a New was selected, or all of the characters were deleted (for example, with repeated deletes or Selected All and Delete). For the first two situations, all of the lines of the program should be reported as deleted, but for the third, the last line should remain and be set as the modified line. The load file conditional occurs when the cursor move failed and the New previously set the modified line to -2. For these conditions, the net line count is set to the number of lines that were in the document, the new line count is set 0 and the change at the beginning of the line flag is set because it is not set when the document is empty.
At the end of the document change routine where the modified line is set to the current cursor line (the end of the change), it needs to instead be set to -1 if it currently set to a -2 from a New operation, so that the first (and only) line in the document after a New operation is not marked as modified.
One other minor problem was also discovered when an empty file is loaded and the document was previously not empty. The window modified flag was set (shown with an asterisk after the file name in the window title bar). I'm not sure why this occurs, but it was corrected by clearing the window modified flag after a program is loaded and the document is set. Reseting the edit box document's modified flag was not sufficient.
Finally, it was noticed that the program view list widget was grabbing focus when a new file was loaded or New was selected as evidenced by the edit box cursor disappearing and the focus could be seen be the light blue focus indicator around the widget. This list view widget was prevented from grabber focus by setting its focusPolicy property to NoFocus.
[commit 65bd6a9233]
Saturday, March 9, 2013
Viewing Program Changes
To monitor the contents of the program, which will be updated by the program changed signal, a Program View dock widget was added to the right side of the application GUI using Designer. A dock widget can be docked to any side of the window, through this dock widget was restricted to the left and right sides. A dock widget can also be undocked from the main window.
A QListView widget was added to the Program View dock widget. The editTriggers property was set to NoEditTriggers to prevent editing and the selectionMode property was set to NoSelection to prevent selection. In other words, this list view was made read-only.
A QListView is meant to work with a data model. Eventually a custom Program Model will be created that will hold the program. The MainWindow class will contain a pointer to the Program Model. To keep it simple to start, the predefined QStringListModel was used. This model simply maintains a list of strings, which for now are set to the program line strings.
The program model is instanced in the MainWindow constructor, which must be done before the edit box is instanced, since the edit box will generate a program change signal. This model is then assigned to the QListView widget. Any changes to the model will be reflected in the dock widget. The program changed slot in main window was modified to update the program model as changes are received instead of outputting the changes to the console.
[commit 60e125362e]
A QListView widget was added to the Program View dock widget. The editTriggers property was set to NoEditTriggers to prevent editing and the selectionMode property was set to NoSelection to prevent selection. In other words, this list view was made read-only.
A QListView is meant to work with a data model. Eventually a custom Program Model will be created that will hold the program. The MainWindow class will contain a pointer to the Program Model. To keep it simple to start, the predefined QStringListModel was used. This model simply maintains a list of strings, which for now are set to the program line strings.
The program model is instanced in the MainWindow constructor, which must be done before the edit box is instanced, since the edit box will generate a program change signal. This model is then assigned to the QListView widget. Any changes to the model will be reflected in the dock widget. The program changed slot in main window was modified to update the program model as changes are received instead of outputting the changes to the console.
[commit 60e125362e]
Entire Loaded Program Detection
The only remaining use of edit box ignore change flag mechanism was to stop detection when the document was set using the reimplemented setPlainText() function, which set this ignore flag before calling the base class function and cleared it afterward. The document change function upon seeing this flag set returned without processing the change.
Since it was now desired to process this change and report all lines as being added, the ignore flag mechanism was removed. Also, the remaining functionality of the reimplemented setPlainText() function was calling the base class function and then setting the line count variable. The line count variable will now be set by the document change function, and since this function was only calling the base class function, it was also removed.
For some strange reason, there are actually two document contents change signals generated when the document text is set, one where it indicates one character removed and none added, and a second one with no characters removed and the number of characters in the file added. My guess is that the first signal is generated from the document being cleared before being set, and the one character is an empty line where the document always contains at least one block (with a single new line).
This first change signal needed to be ignored, which can be accomplished by checking if the document is empty. However, this is not the only case where the document could be empty (like if all the characters were deleted). Another indicator was needed for this condition. The document change function does a move cursor position by the number of characters added to determine where the cursor will end up. It turns out that this function returns whether the move succeeded. If the document is empty, this move fails, so this status is captured. If the document is empty and the move failed, the document change function only resets the modified line and returns.
The cursor position move also fails when with the second signal because the number of characters added is one more than the cursor can be moved. Since this move fails, the number of lines modified ends up being zero instead of being set to the number of lines in the document that were added. To emit the correct number of lines inserted, the number of lines changed is only adjusted if the cursor move succeeded or the number of lines modified is not less than the net line count change when lines were added to the document.
[commit 23c1ace139]
Since it was now desired to process this change and report all lines as being added, the ignore flag mechanism was removed. Also, the remaining functionality of the reimplemented setPlainText() function was calling the base class function and then setting the line count variable. The line count variable will now be set by the document change function, and since this function was only calling the base class function, it was also removed.
For some strange reason, there are actually two document contents change signals generated when the document text is set, one where it indicates one character removed and none added, and a second one with no characters removed and the number of characters in the file added. My guess is that the first signal is generated from the document being cleared before being set, and the one character is an empty line where the document always contains at least one block (with a single new line).
This first change signal needed to be ignored, which can be accomplished by checking if the document is empty. However, this is not the only case where the document could be empty (like if all the characters were deleted). Another indicator was needed for this condition. The document change function does a move cursor position by the number of characters added to determine where the cursor will end up. It turns out that this function returns whether the move succeeded. If the document is empty, this move fails, so this status is captured. If the document is empty and the move failed, the document change function only resets the modified line and returns.
The cursor position move also fails when with the second signal because the number of characters added is one more than the cursor can be moved. Since this move fails, the number of lines modified ends up being zero instead of being set to the number of lines in the document that were added. To emit the correct number of lines inserted, the number of lines changed is only adjusted if the cursor move succeeded or the number of lines modified is not less than the net line count change when lines were added to the document.
[commit 23c1ace139]
Newly Inserted Lines Fix
When a new program is loaded, the entire program must be loaded into the document (as plain text) and the class that will hold the encoded program. One method would be to set the edit box document to the plain text of the program and then set the program class. Another method is to allow the program change signal that would be emitted when the document is set to the text of the program (which is presently disabled).
After re-enabling the signal when the document text is set, and trying to get the proper signals to be emitted, I discovered that newly inserted lines were not always being emitted correctly. A simple example of this is when a return is entered at the end of the new line - the line was reported as changed instead of inserted.
This problem occurred because the code needed to check if the current modified line is going to be new, but was not previously new before adjusting the number of lines changed and inserted for the new line. When the line is new, but wasn't previously new, the number of lines modified is incremented by one and the number of inserted lines is decremented by one to account for the new line that hasn't been inserted yet.
The aid in debugging, a status indicator character was added to the line number widget after the line number of the current line to indicate when the current line is modified (with an asterisk) or is new (with a plus). This is easier than having a message on the console indicating the line number modified and new status, and then having to refer to edit box to see which line the cursor is at.
[commit 9f15211791]
After re-enabling the signal when the document text is set, and trying to get the proper signals to be emitted, I discovered that newly inserted lines were not always being emitted correctly. A simple example of this is when a return is entered at the end of the new line - the line was reported as changed instead of inserted.
This problem occurred because the code needed to check if the current modified line is going to be new, but was not previously new before adjusting the number of lines changed and inserted for the new line. When the line is new, but wasn't previously new, the number of lines modified is incremented by one and the number of inserted lines is decremented by one to account for the new line that hasn't been inserted yet.
The aid in debugging, a status indicator character was added to the line number widget after the line number of the current line to indicate when the current line is modified (with an asterisk) or is new (with a plus). This is easier than having a message on the console indicating the line number modified and new status, and then having to refer to edit box to see which line the cursor is at.
[commit 9f15211791]
Line Change Detection Complete
The detection of program line changes should now be complete. This feature is necessary so that program lines can be incrementally compiled as they are modified. Even though the implementation was starting to look rather complicated, it turned out to be fairly simply, which was mostly concentrated in the processing of the edit box document's contents change signal that contained sufficient information to report line changes. From the time the new implementation was started, the size of the edit box code was reduced by about half and the previous implementation wasn't complete.
The next step is to connect the new program changed signal from the edit box to some new program class that will eventually hold the BASIC program code, though the goal of the current 0.3.x release series is to get the translator part hooked up. However, this is a good point to make a development release. In preparation for this, there was some minor cleanup of the code:
[commit a2cfa5361a] [commit a13c485632]
The next step is to connect the new program changed signal from the edit box to some new program class that will eventually hold the BASIC program code, though the goal of the current 0.3.x release series is to get the translator part hooked up. However, this is a good point to make a development release. In preparation for this, there was some minor cleanup of the code:
- Renamed the edit box line number widget related functions with the consistent prefix of lineNumberWidget (separate commit).
- Corrected a memory leak of the edit box instance by assigning the main window as its parent.
- Removed the setting of the ignore change flag at the end of the edit box key press event handler (this flag is now only used when a new program is set).
- Updated the copyright of the modified files and a few other very minor changes.
[commit a2cfa5361a] [commit a13c485632]
Friday, March 8, 2013
Capture Modified Line Upon Saving
If the edit box has a modified line, it needs to be reported before the program is saved. This is accomplished by calling the capture modified line routine (currently called when the cursor is moved from a modified line) in the save program routine. This required the capture function to be made public. This function already contains a check if there is a modified line before reporting a change, so if there is not a modified line, no action is taken.
[commit 0561cc9a64]
[commit 0561cc9a64]
Save Action Enabling
There is a feature in LibreOffice where the save action (menu and tool bar) is only enabled when the document has been modified, otherwise it is disabled. Microsoft Office does not have this feature. This feature was simple to add and only required the edit box's document's modification changed signal to be connected to the save action's enabled slot.
[commit 93c856dcb4]
[commit 93c856dcb4]
Select All Correction
While testing, it was noticed that when using the Select All (Control+A) key sequence to select the entire document, a cursor position change signal was not being received. The prevented a line changed signal from being emitted if the current line was modified. The cursor should be moved to the end of the document. Using Select All from either the Edit menu or the context menu did work correctly. This problem was corrected by intercepting the Select All key sequence and calling the select all function that was connected to the menu actions.
[commit 6a7c9c57e4]
[commit 6a7c9c57e4]
Detecting Changes With Undo/Redo
Curiously, when the document's contents change signal is received for an undo or redo operation, the cursor has not been moved yet, so the current cursor position cannot be used to determine the number of lines changed from its line number and whether the cursor is now at the end of the line.
The beginning of the document changed slot function was modified to get the current text cursor and set its position to the position of the change. The line number of this position and whether this position is at the beginning of the line is obtained. This cursor is then moved to the end of the change by moving the cursor right by the number of characters added by the change. This method also works for all of the other types of document changes. Several of the local variables in the function were renamed to make the code clearer.
The reimplemented undo and redo functions are no longer deleted and were removed along with the checks for the undo and redo key sequences in the key press event handler. It is also no longer necessary to keep track of the undo and redo operations on the current modified line, so the undo added slot was removed along with the modified line count and undo active variables. This mechanism was originally implemented to keep track of changes on the current line so that unnecessary line change signals were not emitted, but now the receiver of this signal is will be responsible for detecting actual line changes (see post on March 3).
[commit a9db922c4d]
The beginning of the document changed slot function was modified to get the current text cursor and set its position to the position of the change. The line number of this position and whether this position is at the beginning of the line is obtained. This cursor is then moved to the end of the change by moving the cursor right by the number of characters added by the change. This method also works for all of the other types of document changes. Several of the local variables in the function were renamed to make the code clearer.
The reimplemented undo and redo functions are no longer deleted and were removed along with the checks for the undo and redo key sequences in the key press event handler. It is also no longer necessary to keep track of the undo and redo operations on the current modified line, so the undo added slot was removed along with the modified line count and undo active variables. This mechanism was originally implemented to keep track of changes on the current line so that unnecessary line change signals were not emitted, but now the receiver of this signal is will be responsible for detecting actual line changes (see post on March 3).
[commit a9db922c4d]
Before Selection Not Needed
Previously, information about the selection before a document change operation was saved. This information was used to figure out what text was replaced by the operation. This is no longer needed because this information can be determined from the position received in the document's contents change signal and from the current cursor position, which is at the end of the change.
Therefore, the before selection no longer needs to be saved. Also, since this was the only use of the Selection class, this class was also removed.
[commit ebffb4445c]
Therefore, the before selection no longer needs to be saved. Also, since this was the only use of the Selection class, this class was also removed.
[commit ebffb4445c]
Thursday, March 7, 2013
Adjusting/Correcting Return Key Behavior
Previously, a Return key only inserted a new line when the cursor was at the end of a non-blank line. Otherwise, the cursor is moved to the beginning of the next line. This will reduce accidentally breaking lines in the middle of them. The Control+Return key was implemented to insert a new line always. Upon, using the edit box for a while, I decided to make Return insert a new line when on a blank line.
A problem was corrected when there was a selection, a Return key ignored the selection an moved to the next line instead of replacing the selection. The code was changed to only move to the next line when there is no selection.
There was also a problem when a selection went across two lines, with part of the second line selected. A Control+Return key entered should replace the selected text with a new line, which it did, however, the edit box contents were no redrawn properly where the selected characters on the second line remained selected on the screen. These characters were not actually selected and the were deleted from the document. Must be some sort of bug in the Qt libraries or the libraries routines were not being utilized correctly.
This problem was corrected by replacing the insert text call of a new line with the creation of a new key press event with a Return key, calling the QPlainTextEdit base class key press event handler, deleting the key press event and returning.
[commit a8b9f09778]
A problem was corrected when there was a selection, a Return key ignored the selection an moved to the next line instead of replacing the selection. The code was changed to only move to the next line when there is no selection.
There was also a problem when a selection went across two lines, with part of the second line selected. A Control+Return key entered should replace the selected text with a new line, which it did, however, the edit box contents were no redrawn properly where the selected characters on the second line remained selected on the screen. These characters were not actually selected and the were deleted from the document. Must be some sort of bug in the Qt libraries or the libraries routines were not being utilized correctly.
This problem was corrected by replacing the insert text call of a new line with the creation of a new key press event with a Return key, calling the QPlainTextEdit base class key press event handler, deleting the key press event and returning.
[commit a8b9f09778]
Wednesday, March 6, 2013
Issues With Newly Inserted Lines
The edit box contains a variable to indicate when a line has been inserted but not yet reported as being inserted (in other words, a new line). Lines are not reported as being modified (changed) until the cursor leaves the line. This will prevent unnecessary compiling of the line as it is being entered. This includes a new line that is being entered. There were some issues with new lines that were corrected.
A new line can only occur when multiple lines have changed or a single line has changed and the change is not at the beginning of a line. After a change, the modified line is marked as new if there was a single line change and the change was not at the beginning of a line or if the cursor is at the end of a line. The problem was with this last part when the change was due to a delete at the end of a line and the next line was blank (the cursor was still at the end of the line). This was corrected by checking if characters were added by the change.
When on a new line, if a backspace occurs is entered the beginning of the line or a delete at the end of the line, the current line or the next line was being reported as deleted, but a new line wasn't reported as inserted yet. This was corrected by adding a check if the current line is modified and new, to reset the status of the line to just modified, and to not report the line that is removed as deleted. This change caused another minor problem where an empty lines changed signal was emitted (no changed, deleted or inserted lines), so this empty signal was prevented.
The variable being used to indicate whether a modified line was changed or inserted (new) was an enumeration, however, this enumeration only had two values. To make the code easier to read, the variable was renamed and changed to a boolean variable.
Finally, deleted lines were not always reported correctly in the main window's program changed slot that is temporarily connected to the lines changed signal for debugging. The deleted lines loop was corrected so that these lines are reported correctly.
[commit f10eca50ba] [commit 4364d7447f] [commit 74a5eb93a0] [commit 53bf17fda2]
A new line can only occur when multiple lines have changed or a single line has changed and the change is not at the beginning of a line. After a change, the modified line is marked as new if there was a single line change and the change was not at the beginning of a line or if the cursor is at the end of a line. The problem was with this last part when the change was due to a delete at the end of a line and the next line was blank (the cursor was still at the end of the line). This was corrected by checking if characters were added by the change.
When on a new line, if a backspace occurs is entered the beginning of the line or a delete at the end of the line, the current line or the next line was being reported as deleted, but a new line wasn't reported as inserted yet. This was corrected by adding a check if the current line is modified and new, to reset the status of the line to just modified, and to not report the line that is removed as deleted. This change caused another minor problem where an empty lines changed signal was emitted (no changed, deleted or inserted lines), so this empty signal was prevented.
The variable being used to indicate whether a modified line was changed or inserted (new) was an enumeration, however, this enumeration only had two values. To make the code easier to read, the variable was renamed and changed to a boolean variable.
Finally, deleted lines were not always reported correctly in the main window's program changed slot that is temporarily connected to the lines changed signal for debugging. The deleted lines loop was corrected so that these lines are reported correctly.
[commit f10eca50ba] [commit 4364d7447f] [commit 74a5eb93a0] [commit 53bf17fda2]
Monday, March 4, 2013
New Line Change Detection – Backspace
A check for the backspace key was originally added to catch the situation where a backspace at the beginning of a line combines the line with the previous line, causing the current line to be deleted. There were a number of conditions that needed to handled that eventually the functionality was put into a separate function (for details, see posts on January 30, February 3, February 6, February 7, and February 9).
The document changed slot function now handles this backspace operation, so the backspace key no longer needs to be checked for and the backspace function was removed. However, there is a situation with the backspace that is not yet being handled correctly (that was by the backspace function), specifically if a backspace at the beginning of the line occurs on a line currently marked as a new line not yet inserted. The line is currently reported as being deleted (but was not yet actually inserted).
There are a number of other situations where the modified line is marked as inserted that are not being handled properly by the document changed function. One case, this function is incorrectly marking the line as newly inserted if the cursor is at the end of the line after the document change. This is correct only for some situations. These issues will be addressed next.
[commit 9b1d127f93]
The document changed slot function now handles this backspace operation, so the backspace key no longer needs to be checked for and the backspace function was removed. However, there is a situation with the backspace that is not yet being handled correctly (that was by the backspace function), specifically if a backspace at the beginning of the line occurs on a line currently marked as a new line not yet inserted. The line is currently reported as being deleted (but was not yet actually inserted).
There are a number of other situations where the modified line is marked as inserted that are not being handled properly by the document changed function. One case, this function is incorrectly marking the line as newly inserted if the cursor is at the end of the line after the document change. This is correct only for some situations. These issues will be addressed next.
[commit 9b1d127f93]
Sunday, March 3, 2013
New Line Change Detection – Inserting Text
The insert text function of the edit box was implemented to process text inserted into the program so that changed lines could be detected and reported. It was used to insert a new line, for the return key, the reimplemented pasted function, and the paste selection function (middle-click paste on Linux). This function is not longer needed and was removed. The code for the return key was already changed to simply use the insert text function of the text cursor (and the document change function handles the line change detection).
The other two uses were also updated starting with the reimplemented paste function originally necessary to catch the paste action (menu, context menu, and tool bar) and call the insert text function. The paste function is no longer necessary since the document change slot function will be called for all paste operations. Therefore the reimplemented paste function was removed. The check for the paste key sequence is also no longer necessary (will be handled by the plain text edit base class key event handle, which will call the document change slot function).
The mouse release event handler was reimplemented in the edit box class to catch the middle-click paste of the selection and call the insert text function. This is also no longer necessary, so the handler function was removed. However, the paste selection function, which was called from the mouse release event handler, is also called for the Control+Shift+Insert key sequence to pasting the selection. This is still needed, so the insert text function call was replaced with the text cursor insert text function.
[commit 361f10a7f5]
The other two uses were also updated starting with the reimplemented paste function originally necessary to catch the paste action (menu, context menu, and tool bar) and call the insert text function. The paste function is no longer necessary since the document change slot function will be called for all paste operations. Therefore the reimplemented paste function was removed. The check for the paste key sequence is also no longer necessary (will be handled by the plain text edit base class key event handle, which will call the document change slot function).
The mouse release event handler was reimplemented in the edit box class to catch the middle-click paste of the selection and call the insert text function. This is also no longer necessary, so the handler function was removed. However, the paste selection function, which was called from the mouse release event handler, is also called for the Control+Shift+Insert key sequence to pasting the selection. This is still needed, so the insert text function call was replaced with the text cursor insert text function.
[commit 361f10a7f5]
Subscribe to:
Posts (Atom)