Liveable wage for software development?

Tag Archives: Drawing Workbench

I’m currently visiting with family in the US, will be heading back to home in a few days. The talk in Madison that prompted this trip went fairly well, and I’ve spent the last several days catching up with family and friends – quite nice overall, and beautiful springtime weather!

I’ve not done a lot with FreeCAD so far on this trip; during the ‘work’ segment in Wisconsin I was too busy, and have been trying to treat the second part as more of a vacation. This is, after all, an experiment to see if working as an open source developer can serve as employment, and any reasonable employment must include vacation ;).

That said, there has been a little tinkering here-and-there with some smaller items in FreeCAD, and I’ve been trying to keep abreast of the forum. I suppose a screenshot of the work on editable texts in Drawing hasn’t made it onto the blog yet – some of this work was done on the trip:

Unrelated to FreeCAD; I’ve finally spent a couple afternoons starting to learn some Common Lisp, which I’ve meant to do for a while now. It’s been a very interesting process so far; the language itself has been fun to start learning, but the history behind it is quite interesting as well. This evening, I was reading about interesting uses of Lisp and came across SHRDLU, which was done 45 years ago! http://hci.stanford.edu/winograd/shrdlu/ and then watch video of the real thing https://www.youtube.com/watch?v=bo4RvYJYOzI Amazing!

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!

1) I did a little bit of work on the position dialog box, as requested on the forum a few days back. The position dialog has two modes, incremental and not-incremental (I’ve been calling that one absolute), where the position indicated to the dialog is either applied against an object’s current position (incremental), or against the origin of the coordinate space (absolute). That mode is selected by a checkbox, the requested feature was to make the state of that checkbox persist between uses.

In addition to making the checkbox state persistent, I ended up also changing around the transitions between the two modes a little bit, so now that part works a little more intuitively. Now, when incremental mode is entered, the GUI widgets are initialised to reflect the equivalent incremental placement to the change in absolute position that had been in the GUI before.

I suppose a video clip would’ve been a clearer way to convey the original problem and my changes…

2) The auto-scale in Drawing had a few problems, so I’ve re-worked two areas to resolve those.

First, there’s a little function (Attributed to David Eppstein, whose blog led me off to reading about the Harriss spiral – neat stuff) that takes a scale value and computes a ratio of two integers that closely approximates that scale. The problem was that the function wasn’t really setup for handing big or small scales, so I wrapped it up with a little math to essentially deal with adding 0s onto either the numerator or denominator depending on the scale.

Second, the algorithm for calculating the initial scale to use didn’t handle small scales very well. The re-work there was a little more involved, but fortunately a lot of my earlier work on the placement of orthographic views was useful.

So, now it’s easy to use the drawing workbench for bigger or smaller things than it used to be, though there are still a couple issues. One of them is that there’s a hard-coded level of detail parameter somewhere, which I intend to do something about. So, right now if I try to draw a sphere the size of Earth, then it gets computed to some absurdly high resolution, 0.01mm or something along those lines. There’s a similar problem in the regular 3D view part of FreeCAD too, for instance at the default settings a circle drawn in Sketcher looks like a 30-something sided polygon, so maybe that issue requires a bit more thought.

Yesterday was spent mostly as anticipated – picking up my shiny new/used monitor (quite happy with that purchase) trying out the new Enumeration class (minor success, needs a couple small changes before further testing), tying up some loose ends in Drawing, etc.

From a user’s perspective, the main change to Drawing is that isometric views are now constrained so they’ll only move in 45 degree angles from the Front view, much like the normal orthographic views move only vertically or horizontally from the Front view. I’m not 100% happy with the implementation here, so may do a bit more work on that later – the movement can get a bit jittery when isometric views are moved too near the centre of the Front view, although there’s not much good reason to do that anyway.

But! I also tracked down the source of a bug that’s closely related to the one discussed previously in Bounding Bounding Boxes. Isometric views were sometimes being positioned a little strangely, which became more of an issue after their positions were constrained. The problem is that the centroid of an object’s bounding box is dependant on the orientation of the bounding box. The isometric views end up wanting a bounding box for the object that’s not aligned with the originally calculated one, so they sometimes are not centred on the origin. A fix for that is first up on my list for today, though I’m a bit slow with this Open CASCADE 3D geometry stuff.

Today was supposed to be a “weekend” day, but a number of events transpired to keep me in front of the computer for much of the day.

First off, I spent some time cleaning up the changes I’ve been working on in the Drawing workbench, and getting them pushed up to github. The main two items are a re-work of code involved in generating “wires”, which are what OpenCASCADE calls collections of edges, some work on BSplines, and the isometric projections. There had been a couple bugs in the BSpline and wire code, finding and fixing those occupied most of yesterday. Now, the Isometric projections aren’t completely done, but they’re usable and I just need to make a few design decisions to finish them up.

A couple other smallish bug fixes made it in, and a lot of cleaning up/commenting source code. There’s a discussion ongoing on the FreeCAD forum regarding code formatting/reviews/etc, so have been occasionally getting distracted by thinking about that stuff too.

Will probably take tomorrow “off”, as I need to take care of some things out of the house, but stay tuned!

Select the right (or left or top…) view so that it turns completely blue. than move the front view. You will notice the wrong movement of the selected view (figure out which is better highlight mode between dragging anchor vs child views, and use that mode consistently for both)

Update regions are wrong: seems that only the areas in the dotted view frame get updated, if the text below the view goes outside the view frame this becomes a problem, you see remaining artefacts while moving. this also happens a lot when repositioning dimensions

When adding dimensions to one view the frame of this view updates not correctly

The dimensions get somehow misaligned, they shift on the pages y axis downwards for some reason

If you change from first to third angle the positions of left and right views etc change, but not the isometric views.

For the A4 template it seems impossible to make the dimension font small enough, you would go to size 4 or lower to get something reasonable, but than the font looks really weird. Also 4 is small… normal size for A4 writing is 12, but this is really huge in the drawing workbench compared to text tools like word

Automatic scaling often doesn’t work properly

Repaint around the template to remove artefacts

Drawing viewer widget should resize

Update icons for isometric and orthographic views in the document tree thing. (asked for drawings in the forum)

Save and Save As don’t seem to work while Drawing Viewer is open?

Figure out what’s going on with the two properties for the template name (TODO in 8476bab)

Align isometric views too. From ickby: “Best it to anchor them to the orthographic projections, for example the FrontTopRight would be anchored to the Top view top:top, and the FrontTopRight would be anchored to the right view right:right. This would give always a nice projection grid.”

Selecting the view for draging should work on the whole view area, not only the dotted frame. So only omit the areas where you can select the lines/dotes etc.

Possibly add spinboxes for the scale selector, this would allow change the value with the mouse wheel