I’ve spent much of today working on things to do with the title block in Drawing – both the old and new versions. This morning, there was some investigation into a bug in the old Drawing, then after that I’ve been working on implementing a nice UI for editing text fields from templates…
My idea was to make text in the SVG template be clickable, so the user could just click on the drawing’s title and edit the title, for instance. Sounds simple enough, but the plan involved one slight complication that’s turned out to require a fair bit of effort. It’s easy to extract the coordinates of the beginning of the text from the source SVG file, but it’s not trivial to get the width and height of the rendered text. That’s important because the width and height are required to determine what area needs to be clickable.
There’s a documented function in Qt though, which should allow one to use the SVG ID of an item in an SVG document to get the width and height once it’s rendered. So, I spent some time getting things setup to use that function, and found that it didn’t work. After spending some time trying to figure out where I had screwed up, I found a post explaining that the function I wanted to use wasn’t actually implemented for SVG text items…
Anyways, a couple random distractions later (some related to the PropertyEnumeration refactoring effort, which has been pushed to the main line and so some folks have been forced into testing it 😉 ), and I’m making some progress again on Drawing.
I probably won’t be updating this much over the next few days, as I’ll be travelling, but stay tuned!
Today has mostly been spent in the Drawing module; working on refactoring code, and fixing automatic positioning of individual views (“view” and “viewer” must be the most commonly used word in FreeCAD source code…) in orthographic projections. This is something I started a few days back, trying to resolve the issue where the views were often drawn on top of each other by default. It turned out to be a sneaky little problem; the main issue boiled down to the coordinate systems used for the 6 individual views having different origins from each other, which also changed depending on the projection used.
So, now we can make a drawing of something like the archetypal orthographic projection demo widget:
Then, with a few clicks (and an annoying wait, might attack that tomorrow), have a decent looking drawing in either “third angle” as at the top of this post, or “first angle”:
One small step at a time…
After a nice few days in Fiordland, I’m back at FreeCAD. Specifically, back at trying to improve the Drawing workbench.
I’ve had limited success fixing the rendering problem, but there are several related issues, one solution to all of them seems to be upgrading to Qt5. At this point, I think it’s a better use of my time to go on with improving Drawing than to try making workarounds for the larger “rendering issue”, which only seem to show up on Mac anyways.
Before leaving the “rendering issue” though, here’s a screenshot of the simplest demonstration case – I’ve just opened FreeCAD (built from a recent master branch), opened a document, and switched back to the Start page:
The problem is that the “a cube” window shouldn’t be there. Clicking on that window, including the frame, behaves as if the tab for that window had been clicked – the cube goes to full screen and obscures the Start page. I can stop the cube from being rendered (by disabling updates on the widgets that should be “behind” the current fullscreened one), but clicking in the bottom-right of the Start page in this scenario still switches back to the 3D view. Quite weird.
The upshot though is that the hacky rendering fix (disabling updates) works reasonably well in Drawing, and Drawing handles the mouse clicks properly. So, I’ll get back to working on Drawing for now, and maybe investigate the Qt5 thing a bit more at some other time.
This is going to be a short one – I spent most of the day working on dead-end attempts at fixing that rendering problem, which is more than just a rendering problem, and affects more than just Drawing…
There is some accompanying weirdness in the way mouse events are handled even when I’ve fixed the way the screen looks. If the mouse is clicked over the area where the stray rendering would’ve been, then the mouse gets passed on to the wrong widget. Strangely, the problem doesn’t manifest until the mouse is clicked (mouseover behaves as it should). My suspicion is that it’s a Coin3D-related issue.
A few months ago, I made some modifications to Sketcher that never got committed (to use keyboard modifier keys for selectively disabling snap-to-grid and automatic constraint creation), I think those modifications involve a similar code path to what mouse events are using here. Brain is too fried to look at that today, I ran into some snags getting a debugger setup, and I need to go buy some groceries for tomorrow’s Fiordland trip!
At this point, I think the next thing I’ll try is stepping through the path a mouse click event takes to see if there’s an obvious problem. If that doesn’t lead to a solution, then either continue on to something else, or construct a minimal test case outside of FreeCAD.
Back in a few days, and thanks for all the support!