Tag Archives: 80/20 rule

Incremental changes

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.

little things, and The Process

While I was playing around with FreeCAD today, I felt a little twinge of frustration and decided to do something about it. Perhaps my loyal reader will find the process of identifying issues, fixing them, and publishing fixes interesting?property viewer

There’s a widget, the “Property Viewer”, which is one of a few key GUI components in FreeCAD. It contains two lists of properties (dimensions, positions, colour, etc.) for the thing you’re working on, and allows them to be changed. There are other ways to change most properties too, but the Property Viewer has everything in one place and is usually accessible.

The Property Viewer has two tabs; Data and View, so you can either work on Data properties or View properties at any particular time*. The issue is that I manipulate Data properties much more frequently than View properties, but FreeCAD always starts up with the View tab in front. So, I usually have an extra click to get Property Viewer in the right mode for changing the properties I’m interested in.

To fix this, I added ~20 lines of code to save the last tab that was selected, and to select that tab next time FreeCAD opens. Then, I “pushed” that modification to github, and made a brief post to the FreeCAD forum to ask people to try it out and comment. Assuming that my change doesn’t cause any problems and people like it, in a few days I’ll submit a “pull request” and one of the core developers will bring the code in to the main FreeCAD codebase (unless they notice a problem in the new code). Not all changes justify asking for popular opinion and testing, but that’s a judgement call. This particular change affects a core GUI component of FreeCAD so I felt like it was worth asking.

Every now-and-then, a “release” is made of FreeCAD (incidentally, we just made a release today!), next time that happens, any changes incorporated to that point will be included. Releases happen every few-to-several months, so in the meantime people can only get the new changes by building from the latest source code, which is what some of the early posts on here, for instance the one about building on OS X, are about.

All that said, the process for the Drawing module, which is where I’ve been doing most of my work lately, is a bit different. At this point there are only a couple people working on that module, and we’re working on a fairly significant re-write that involves breaking the existing Drawing module. So, rather than asking for comments and incorporating changes into the main FreeCAD, we [even more] informally push and pull our work to/from github to keep the latest and greatest moving forward. Eventually, when there’s some consensus that the module is ready to go, we’ll go through a testing phase with the wider FreeCAD community, and hopefully the whole thing will eventually be a part of the main codebase.

* Of course, as I type this, I realise that it might make sense to just get rid of the tabs altogether and just put all properties in one widget…

More about file opening

Today, I spent a couple hours trying to understand, and possibly re-work some of the FreeCAD bits involved in opening documents following yesterday’s diversion.

In the end, it looks like “fixing” this would take a bit more effort than I want to put into it, for a rather small gain compared to some other areas. So, if anyone else is interested in a project, there’s a branch here https://github.com/ianrrees/FreeCAD_tinkering/tree/read-unordered-zips that has some of the work done, but I think the proper solution will involve getting rid of the current istream-oriented approach in favour of something that’s file/database/XML-oriented. Basically, I’d start with removing the current Base::Reader’s inheritance from istream, then replace the getStream() with something more like getStream(specific_filename). Right now, Base::Reader has an awkward “is-a and has-a” relationship with istream, which in my opinion needs to go away. The combination of the XML parser, and only maintaining stream handles (versus handles to the original input file) is why we have the requirement for files to be stored in a specific order inside the FCStd file.

Have put also some time into updating the wiki, making some notes, doing some testing, and putting together a small patch that improves the error handling and reporting around improperly formatted input files.

Another TO-DO too: When a file fails to open properly, it should either not leave an open partially-loaded document in the GUI, or it should prompt before saving over the original document. As things are, it’s really easy to “shoot yourself in the foot” if FreeCAD fails to open a file, because hitting “save” will overwrite the entire original file with only the bits that FreeCAD managed to open successfully…


… = 4?

Also known as the Pareto Principal, the “80/20 rule” is something that detail-oriented people like me need to keep in mind. It applies very well to software development, one example being a quick bit of code last night that’s now in the latest-and-greatest FreeCAD development source:

rendering issue popup

I dig the idea of wiki links in error messages, by the way

To “fix” 80% of the problem that causes the 3D view popping up in the Drawing here, I’m working on a 2-part solution, which should hopefully be far less than 20% of the effort of the proper solution. The first part was to make a little popup, only on Macs, whenever the customer starts using MDI style windows. I don’t think that adding popups is generally the best solution, but in this case the proper solution would involve a large amount of time/effort – essentially adapting both FreeCAD and a large external library to use Qt5. The warning seems to strike a reasonable balance, so I went ahead and submitted that part last night.

The second part applies only to the development version of Drawing, I think. Stay tuned!

Cost: Probably 2 cups of tea, though I wasn’t keeping close track

On a tangent, another example of the 80/20 rule in my [funky, new-to-me] house from this morning – the clothes washer and dryer weren’t meant to go together as a vertical pair, so there used to be a problem with holding the washer door open. Not anymore!

Dryer fixDryer fix-2