Category Archives: Uncategorized

Back home, and wrapping up the experiment

I’ve been back in Dunedin for a few days now from a trip to the US. The talk went well, and it was great to catch up with friends and family in the states, but I’m also glad to be home!

Aside from catching up on sleep and chores over the last couple days, I’ve been kept somewhat busy with arrangements to start a new job next week. The new role involves software work with a local tech company (which also makes hardware, so may get into that), and I’m quite excited to get started.

The premise of this experiment was to try to fill a gap between jobs, so I suppose the onset of this job marks the end of the experiment. I think this project has clearly demonstrated that it is possible to be supported by the OSS community in exchange for work on an OSS project.

Of course, I’ve still got several irons in the fire with FreeCAD, so my plan is to keep working on it as time allows. I’ll likely post here again with updates, but expect the pace to be more like it has been in the last couple weeks, rather than toward the beginning of this project ;).

Speaking of… My work on FreeCAD over the last few days has been pretty slow, obviously, but I have been trying to follow the forum, get some minor fixes ready to go, and tinkering a bit with the Drawing module. My main project yesterday (aside from getting caught up and remembering what I was doing…) was to fix an annoying little bug where newly-added views within a Drawing would move slightly after being added initially. It was just a small thing (and a one-liner fix in the end), but it struck me how much nicer the creation of a drawing was after that fix. There’s still a lot to do in the Drawing module, but it seems to be on the home stretch now.

To close this post, I’d just like to send a big “Thank you!” to everyone who contributed to this experiment, especially Aleph Objects, you’re all great!

Travel, Lisp, etc.

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:Screen Shot 2015-05-07 at 12.50.29 pm


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!

lisp_cycles_cropped

Quick git tip – global .gitignore

Another minor annoyance removed by a quick configuration change on my system. First, create a file ~/.gitignore_global and add configuration as normal for .gitignore. Then, do:

git config --global core.excludesfile ~/.gitignore_global

Voila! No need to see those omnipresent .DS_Store files from Finder in git’s output anymore!

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…

Bounding bounding boxes

Today, and a little bit of yesterday too, were involved in a bit more geometry-related than most of my FreeCAD time so far. That’s a good thing, I think, but a bit tedious at times.

Without getting too far into boring details, there were some problems in the Drawing module, which boiled down to objects having bounding boxes that weren’t centred on the origin of their coordinate space. This is a problem because the position of things displayed on the screen (eg one of the orthographic views), is calculated in part based on the object’s bounding box, which is assumed to be centred on the origin of the object’s coordinate space. So, with the bounding box origin changing, the position of the object would in turn change, and make things move around on the screen in odd ways.

Getting a little closer to boring details, the issue was that a scaling operation used the wrong origin – the objects were being projected to 2D, then scaled using the origin of the original 3D coordinate space. Result is the top situation, where the scaling operation “pushes” the object off to the upper-right. The solution is just to be mindful that the operations are combined properly, so that the scaling uses the centre of the object as the origin.
bb scaling issue

The patch behind the orthographic projections post basically corrected for this error at a later stage, so now that fix is unnecessary and future work will hopefully be a bit more intuitive! That’s how it goes though; it took a “first draft” solution to see what the problem actually was, then the final draft got a better solution, but obsoleted the first.

Have also put a few hours in to work on the file opening stuff – the patch I submitted has some issues on Windows (unicode…), and so have put together another version. Unfortunately, the second iteration involves some changes to an “external” (quotes as it wasn’t written specifically for FreeCAD, but is packaged with FreeCAD’s source code) open source library, so not sure how that’ll go over. It’s a really annoying problem; basically the issue is just that we can’t confirm the filename of the first file stored in a zip file…

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…

FCStd Format

I went on a bit of a tangent this afternoon – the plan was to continue with some work around projections in the Drawing module, but I got distracted by working with the text in the bottom-right corner of the page…

That led to me wanting to modify a Drawing’s SVG template inside an existing FreeCAD document, which I don’t believe the Drawing module can do yet. I knew that the FCStd file format that FreeCAD uses is just a Zip container, so unzipped the file, made some changes, zipped it back up, and watched FreeCAD crash on attempting to open the file…

I discovered an old post on the forum that points out FreeCAD’s expectation that the files in a FCStd container are stored in a particular order. FreeCAD also provides a “Project tool” to handle exactly this situation, but that tool doesn’t seem to work as I expect it to, and the wiki pages for FCStd don’t mention the file storage order requirement.

So, the TODO item here is to, at a minimum, update the wiki pages that relate to FCStd, figure out the “Project tool”, and maybe get rid of the file ordering requirement if it’s not too much work.