Just found out about the history dialog, wish I knew about it sooner.
However, it only works partially with “move object” tool. As shown in the picture below, point A2_a1 is not registered in the history dialog after I do the move object operation.
This makes it difficult to further hack the history. For example, I cannot insert Line_A2_a1_A1 before A3 is created, because point A2_a1 does not exist in history.
I did test your pattern and yes, it doesn’t show the move that you did, or the move that I did. However, when I move down the list a bit & moved the points again, it does show in the History.
I know the developers have been working on the software to tie up some loose ends, I wonder if these errors are a result of that?
Now I noticed a bigger problem. With or without opening the history dialog, now any new move object operation is not registered in the history at all. In the picture below, my last step is to move HG to HG_a13, but this is not shown in history dialog. But I swear new move operation is registered before as shown by the second last step.
Maybe something broke along the way, so I updated the program just now and restarted the computer, but the problem persists. I’ll try with another computer and report soon.
I tried different PC and earlier version but still does not work. But I found a temporary fix. The move operation will only show up in history if I change the origin point other than “center point”, then close and reopen the history dialog.
I took a look and I believe I know what the issue is. The op’s tools are rather an odd tool for several rteasons, but in this case there are 2 options for the origin point to “move / rotate” the group of objects from / around. 1) A point with a valid tool Id 2) The center of the group which has no or a NULL ID.
Problem is the part pf the code that fills the table is looking for the point name with a tool id. For ex below: Normally it’s looking for the “A1” based on A1’s id… but when there is no Id - as in the case of using the Center, the data is empty so the move tool does not show up.
That being said … I just need to put in checks for the op’s tools, and if the Id is NULL the point name = “Center” else the point name = tool’s origin point name.
I should note… the op’s tools don’t have a tool name per se… they have a group of object names. A future improvement would be to display the list of destination objects in the history… it’s just a bit trickier as we have to parse the < source > objects in the file to get the names.
Well, I got it to work with destination points… have to figure out the curves and arc names… which is trickier. Also another annoying thing is the table widget cell items do not accept any text formating - like CR’s or HTML, so figuring out how to format the object names is a pain.
OK… I had to refactor the way the names are created as with the operational tools we need to recursively call each source object toolId to get the name. Of course things are complicated by the fact that “Lines” and “Darts” are not graphic objects. But… I think I got it working. Along the way I removed some more uneccesary translations, and improved the description of the Arc with Radius & Length.
The cursor will now automatically return to the bottom if you move the cursor and insert a new tool OR when you close the history dialog. Yay!
The cursor now resides in it’s own column so the ID formatting doesn’t get janky at the cursor row.
The op tool object names will now display on seperate lines.
The dart tool now displays the correct Point 1, Point 2, and Point 3 in the description. Before it was displaying points 1, 2, and 2.
I still have to resolve 1 issue… that is when an op tool includes objects from another op tool. I need to figure out how to parse the doc / data to find the destination base name. As you can see in the pic below the basenames are missing
BTW… I discovered a feature I didn’t even know about. When you select a tool in the history, it highlights the tool in the draft block.
Ok, I think we’re not quite on the same line here… I definitely want the 2nd part - when you close the History, it must go to the last row.
However, if you want to add more than one tool, I want it to move onto the new tool added so that it’s ready to take the next tool that may reference the previous new tool and cause an error if you forget to move the arrow onto the previous new tool. Does that make sense? And is it possible?
Are you sure it was me and not RT? Although I’m finding I’ve probably forgotten more of the code than I remember. And this was one of those signal / slot things where for ex the History dialog emits this signal:
emit showHistoryTool(id, true);
But with out searching the code for what other class(es) are listening for the signal, you can’t tell what it does. BTW… I just searched and it is an RT thing. Just the code style alone tells me…
He uses upper camel case for methods:
emit ShowHistoryTool(id, true);
which I hate because you sometimes can’t tell at a glance if it’s a class or method. I use lowerCamelCase for methods, UpperCamelCase for classes. It also doesn’t comport with the QT style.
The name is misleading… typical for RT. There’s not such thing as “history tool”. I would use something more accurately descriptive like highlightSelectedTool or something.
Well… don’t thank me yet. Of course in testing the dialog I discovered another bug. If you open the History dialog, move the cursor and insert a new tool. The History table is updated correctly. If on the other hand you are simply appending new tools, the History table is NOT updated. You have to close and reopen the History to show the added tool(s). I think I know where there the issue is.
I know. Here I thought all was working where I just needed to cleaup some commenting and wrap this one up. At first I thought I changed something that screwed up the updating… nope, checked a previous ver and a ver just post of the fork - same (behavior) bug. I’m just surprised nobody has noticed before?
It makes no sense though… has nothing to do with the time travel issue. If the History is open, it should update whether you’re inserting or appending a new tool otherwise it’s leaving the History display in an unkown state. It woud be different if once a new tool is created and it sends a signal to update the History, where in the history update it calls the History to close. Besides… for those that use dual monitors, I can see keeping the History open all the time. It’s really not that different than the Objects dock in Inkscape, CorelDraw, etc.
The big issue though was not automatically returning the cursor to the end of the table after inserting a new tool… otherwise if you don’t, all new tools are inserted rather than being appended, and then you’ve got a mess. That issue I’ve resolved.
Please check when you have a moment?
