Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No coordinates are shown for new part during its placing in 3D view #939

Open
app4soft opened this issue Oct 9, 2024 · 3 comments
Open
Labels

Comments

@app4soft
Copy link

app4soft commented Oct 9, 2024

Describe the bug
No coordinates are shown for new part during placing.

To Reproduce
Steps to reproduce the behavior:

  1. Grab any part from "Parts" list and move it into "3D View" (do not relax mouse);
  2. Keep moving part and look on status bar for actual part coordinates.

Expected behavior
When new part are in adding state show its coordinates immediatly in status bar.

If part are dropped back to "Parts" list (without pasting into scene), in status bar show coordinates of previously active part in scene.

Screenshots

Here is a screencast video. Look on status bar when part is moved from "Parts" list to "3D View".

leocad-part-coordinates.webm

Version (please complete the following information):

  • OS: Debian 12
  • LeoCAD Version: continuous (AppImage)

Crash information:
None

Additional context
None

@app4soft app4soft added the bug label Oct 9, 2024
@malcos
Copy link

malcos commented Dec 29, 2024

I can confirm this is still occurring on a freshly compiled version from master. Not a C++ expert here but I may give it a shot.

Qt Version 5.15.16
OpenGL Version 4.6 (Compatibility Profile) Mesa 24.2.8-arch1.1 (GLSL 4.60)
AMD Radeon Graphics (radeonsi, renoir, LLVM 18.1.8, DRM 3.54, 6.6.65-1-MANJARO) - AMD
Linux 6.6.65-1-MANJARO #1 SMP PREEMPT_DYNAMIC Wed Dec 11 22:24:04 UTC 2024 x86_64 GNU/Linux

@malcos
Copy link

malcos commented Dec 30, 2024

I think I have located the reason of the bug, which is not really a bug, but a missing feature.

Your video is missing an important piece of information: You have no selected part in the 3D model while you place a new part. The issue becomes evident if you select a part in the existing 3d model and then use a drag&drop operation from the part lists. You will see that the part is still selected as you place the new one, and the status bar shows the coordinates of that selected element.

leocad-939-1.webm

Notice how the status bar updates to the coordinates of the new added part after the drop operation completes and it becomes the selected part of the 3d model.

The cause of this resides on how LeoCad updates the status bar: The data is not being "pushed" into the bar, but there is a routine which is "pulling" data from the application, and the coordinates section seems to be using the position of the selected part in the current model... not the location of a piece what is not yet part of the model which is being hovered over the 3d view.

I'll see if I can extract the part for updating the coordinates and then reuse it in the drag&drop/hovering events. I still need to find the place in code triggering this.

@malcos
Copy link

malcos commented Jan 3, 2025

I was not able to solve this task, and since I have timeboxed it I'll pause my work on it for a while. Here my findings just in case someone else wants to pick this issue up.

Summary

There is a central routine UpdateSelectedObjects responsible for updating the state of the UI depending on the selected object, this includes the mStatusPositionLabel used to reflect the coordinates of the current selected piece.

Using some oldschool std::cout << "I'm here, I'm there" debugging I was able to identify 3 problems that need solving in order to tackle this ticket.

  1. The UpdateSelectedObjects routine is not being called during drag and drop operation involving a new piece (or color paint) for the model. But I think I have found the correct location and suiting logic needed to make the call.
  2. I have no idea where the information of the current piece being dragged is stored. I was either too lazy or too ignorant to find that information during my short research.
  3. The UpdateSelectedObjects routine is not taking into account the active piece being dragged, it only focuses on already existing pieces, cameras or light sources.

Points of interest (IMO)

The location where the drag&drop operation starts, creating a QDrag object and storing the current filename of the part being dragged:

Drag and drop events are managed in common/lc_viewwidget.cpp and common/lc_view.cpp, apparently using a view/controller strategy.

Notes:

  • (*a) false indicates mouse drag leave, true indicates mouse drop complete
  • (*b) In this routine we should add the additional call to UpdateSelectedObjects, solving point one from the summary list.

Code responsible to detect currently selected/focused element, it does not contemplate pieces being dragged.

Solving point 1

The UpdateSelectedObjects routine is not being called during drag and drop operation involving a new piece (or color paint) for the model.

After a while I can say with some confidence that the correct location to do this is in lcView::OnMouseMove() @ common/lc_view.cpp#L2780.

But we should avoid doing the call if no drag operation is in progress. One way would be to check that drag state like this

if(mDragState == lcDragState::Piece)
{
	gMainWindow->UpdateSelectedObjects(false)
}

Another way would be by making an assumption: it looks like the variable mTrackTool is always set to lcTrackTool::Insert during this operation. There is already a if branch with this condition in the routine, we could add the call there as well, change it from:

if (mTrackTool == lcTrackTool::Insert)
	ActiveModel->UpdateAllViews();

to

if (mTrackTool == lcTrackTool::Insert)
{
	ActiveModel->UpdateAllViews();
	gMainWindow->UpdateSelectedObjects(true);
}

Solving point 2 and 3

In order to be able to show the position of the current piece being dragged, we need to know where that information is stored, I was not able to find this.

Having the vital piece of information we could either have a special case in UpdateSelectedObjects to get that value instead the one returned by lcModel::GetFocusObject() @ common/lc_model.cpp#L3401. Or we modify the later function to take this into account, at the risk or breaking logic depending on it to only return positions of existing pieces, cameras or light sources.


I may try picking this issue again in the future.

I also have the impression that this bug may be somewhat related to #942

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants