Hardcoded Software devlogs

Refactoring: independent tab views in moneyGuru

Tue, 31 Jan 2012 17:37:26 GMT

moneyGuru started out as a simple account list on the left with an entry table on the right. Then, a new special account was added for displaying all transactions at once. By the time v1.0 was released, there were 4 main "views" (net worth, profit, account entries and all transactions). Later, even more views came along (schedules, budgets), but the code still kept hardcoded reference to each views. moneyGuru would instantiate all available views on startup and show the one the user selected.

It made sense for all views except the account view for which this single view instance thing was quirky. The single account view instance would be shared for displaying all accounts. With v2.0, I added tabs, which allowed for multiple tabs to be opened for the same view, thus allowing for multiple accounts to be opened at once, but the underlying principle stayed the same: Even though there was multiple tabs, behind them was always the same view instance, including for the account view. Swapping account tabs simply told the single account view instance to change its active account. I didn't find it pretty, but it worked and fixing that required a significant refactoring which I wasn't ready to perform in addition to all the things I had to do in v2.0.

Then came a bug report, #252 which was a selection glitch when swapping accounts. Nothing serious, but it was caused by account panes being shared the same view instance. I could have kludged around it, but I have a threshold for kludges. So I waited until I was ready for that big refactoring, which happened in the development of this upcoming v2.5 release.

What I did was to remove all hardcoded references to specific pane views in the main window. It might sound simple, but there was a lot of things relying on these hardcoded references. With pane views being independent, I could finally make the account view instance hold its own reference to its shown account (previously, it was the main window that held it). At last, account views can be present in multiple instances, each with its own account reference. Other pane views could technically also be present in multiple instances, but the benefits of this would be dubious, so to save memory and to save myself from having to fix a few minor bugs that would appear by allowing this, I force all non-account tabs to share the same view instance.

Another very interesting side effect of this refactoring is that it makes the implementation of an eventual plugin feature much easier. I've been thinking about a plugin feature for a while, but so far dismissed it for its low value/work ratio. But with that refactoring done, I think it could be very easy to implement and bring some very interesting possibilities to moneyGuru. No cash flow report? A relatively simple 10-20 lines plugin could do that. I'm even thinking about implementing it for v2.5. It would initially be limited in features (something like only being able to create views with a read-only table, to test the water), but even a limited plugin feature could be immensely useful in some cases.

Upcoming: moneyGuru 2.5

Wed, 25 Jan 2012 18:00:00 GMT

I'm starting to work on the next feature release for moneyGuru. I've already selected the tickets I'm going to work on. There aren't many, but the recent conversion to objp is already a pretty big change and I don't want to push too much into this release.

First, I continue in the visibility options improvements by allowing graphs to be full screen (by that I mean to be the only visible element in a tab). This is to make way for an improvement in the pie charts, that is a dynamic number of slices depending on how much space it has. The number of slices in the pie charts is currently hardcoded at 6 because with the space it has, there's not much more that we can possibly cram into it without rendering the chart unreadable. For users with few accounts, that works alright, but some users have many accounts and 6 slices is useless to them because the "Others" slice is by far the biggest slice.

Another notable improvement to come is increased usability for users with disabilities. I never designed moneyGuru with these users in mind, but I've been told that a few minor tweaks would go a long way, so I'll make those tweaks.

The road to a simpler python embedding in objc

Sat, 07 Jan 2012 18:00:00 GMT

Since the release of dupeGuru 3.3.0, which updated the version of pyobjc to fix a x86_64-related crash, I've been receiving even more crash reports than before. I've suspected libffi -- which is used by pyobjc -- to be the culprit but my skills for playing in that kind of code are woefully inadequate. Moreover, I couldn't even manage to reproduce those crashes on my machine, so I didn't dare file a bug report in pyobjc for a crash that I couldn't reproduce. I also couldn't simply go back to the previous pyobjc version because that would have re-introduced a crash that the update fixed.

Moreover, while I was asking myself how the heck I could possibly fix this, that idea that pyobjc was overkill for what I used it for kept crawling back into my thoughts. After all, it's true that I only use a very small part of pyobjc's capabilities.

That's how I came to experiment a little bit and create objp. Like pyobjc, it's a two-way bridge between Python and Objective-C, but instead of dynamically bridging those two birds on runtime, it takes the code generation route: for Python-->ObjC, it generates code for a Python extension module, and for ObjC-->Python, it generates an ObjC proxy class that simply uses Python's C API to call methods on that Python class it's proxying.

The advantage of this is that you get rid of all these 32-bit/64-bit/alignment/other-complicated-stuff problems because the generated code is static. When dynamically calling a method in C, if you send a short instead of a long you'll get a crash because, well, because (I told you, I don't know much about these things). Of course, libraries like libffi makes sure you don't do that (or does it?), but it can have bugs. Who knows, maybe all those fancy new compilers (llvm and stuff) make libfii's job more complicated and cause those crashes my users were getting. With generated code, the compiler takes care of making all those pieces fit together.

Objp's capabilities are much lesser than pyobjc, and it's meant to be thus. If you tried to wrap the whole Cocoa library in objp (it would have to be a future version because for now, objp is way too simple to even dream of doing that), you'd end up with a very large binary. Objp is meant to help you embed Python in an ObjC app. The interface to python code in my own apps is rather simple, so I can afford to build a very simple solution to that problem.

The work on objp isn't finished yet and I still use pyobjc in my apps, but the limited usage I've introduced in dupeGuru lately are encouraging because users tell me that they don't experience crashes anymore, so I'll continue down that road.

On a different subject, I consider that my recent efforts to improve the internationalization system in my apps were well worth it because the localizations I've received since then have been much easier and quicker to process.