bzr branch http://intuitive-desktop.org/bzr/main/

Merging is SOOOOO much easier in Bazaar.

Also. I stumbled over a tool called Meld Diff that is very useful when you need to perform complex merges that can’t be performed automatically.

Look at the pic. You can click the little arrows to merge each section, one-by-one.

And I can’t. For the past week, I have been trying to simply compare two branches. I’m not even at the fucking merge stage. Just comparing. It either takes 30 minutes, or fails with some strange error (possibly a timeout):

svn: PROPFIND request failed on '/intuitive_desktop/!svn/bc/209/trunk/IntuitiveFramework/Models'
svn: Processing PROPFIND request response failed: required string: "lp1:version-name" (/intuitive_desktop/!svn/bc/209/trunk/IntuitiveFramework/Models)

I keep having to push the release of 0.5 back, because of shit like this. So close and yet so fucked in the side of the head.

(20 MB OGG) -

And for the love of Reason. Please mirror this of you are going to link it to a high bandwidth site.

Usually when people write their unit test, they are just trying to get them to work. The point of view they have is the Test Case Point of View. A developer with this point of view will have these goals:

1. The framework needs to be robust enough to satisfy all the unit tests
2. Once all the test cases are covered, and pass, the code is done

Now most developers would stop here, without moving on to the next stage. But they would discover that their framework was hard to use, redundant, or unnecessarily wordy. Or worse, only their users would find that out.

The next stage is the Usability Point of View. In This stage, the developer should make many example applications using their framework. This includes “Hello Word” applications as well as large apps that try to test the limits of the framework. And Don’t forget cloning neat little apps, like Cairo Clock or Tomboy. While doing this, they should try and focus on these items:

1. Too much configuration or the innards of the framework being exposed for no reason
2. If you end up writing unit tests that test both the application and the framework, this is a sign that there is too much overlap in parts of the framework. Remember Model View Controller.
3. If the framework is very wordy or has a lot of options that should be consolidated, that can cause example programs to bloat up and get very long.
4. There should be very little coupling. If every time you add new code, you have to add multiple dependent pieces of code to deal with that one new thing, that is called Coupling to The Nth Power. That leads to a framework that grows exponentially, and is concrete, near impossible to change, and usually requires a lot of code to do even simple program. Examples of this are The .NET Framework, and J2EE/JBoss.
5. If you run into a problem that requires a change in the framework, and it would be “very unpleasant” to fix that problem, that is a bad sign. Everything should be as easy to change as possible.
6. If you are having to write a ton of comments to explain some voodoo that is happening in the framework, that is a sign that the naming in the framework is confusing, or that there is too much overlap in the classes.
7. If you are not enjoying yourself while making the framework, that is a bad sign. That should be fixed too.

Now that is a pretty large list of things to look out for. I would say the one that I often run into is number 3. I always end up having too many options, or overlapping options in my classes. I even ran into that problem this evening, (which inspired me to write this) while working on a Cairo Clock clone.

Just for fun, I will go over the thing that caused the example to go wrong: I was writing the part that uses data binding to attach the SVG images to layers in the Drawing control. Now the Cairo Clock has a lot of layers. I think it is 12 layers. So for each layer I had to write a binding just to connect it to the SVG file. The binding looks like this:


<Layer name="clock_drop_shadow">
<Binding name="image"
model="ClockImages"
view_properties="image_file"
model_properties="clock_drop_shadow_image"
on_model_change="save_changes_to_view"
on_view_change="do_nothing" />
</Layer>

Basically we have a Layer with a Binding. The Bindings job is to connect the View to the Model. This one connects the ‘image_file’ property of the View to the ‘clock_drop_shadow_image’ property of the Model. It connects them so that it automatically updates the View when the property in the Model changes. Now this is a great way to do data binding, much better than anything that is out there. But as said above, it is too much code for something that will have to be used many times in each object. Not surprisingly, this revelation has come up by writing an example that requires a lot of data binding.

Now to fix it we can do this:


<Layer name="clock_drop_shadow">
<Binding name="image"
bind_direction="view_to_model"
property_map="image_file:clock_drop_shadow_image" />
</Layer>


This looks good. It solves the duplication problem of having two properties that are used to say how the binding direction flows, and the problem of having two properties to hold the way we map one set of properties to another. It also uses fewer lines, and could even be squished into one line.

So it worked. We went one step further, and used our Usability Point of View, and now we were able to make the code more usable, where we would not have seen a problem. So keep those two points of view in mind next time you are developing a framework. And if you have any tips on improving this concept, or have any success stories to tell, email (mattjones@workhorsy.org) me, because I love this shit.

I started with C#. That went down in flames because of the huge overhead in startup time for large assemblies. It also did not have all the code implemented on the Mono side of things. I wanted an easy-to-use language, with all the great Linux technology, like DBus, Cairo, Hal, and GStreamer.

At that point I decided that I was being too much of a wussy, and was going to use C/C++. That quickly crashed and burned as I re-learned why I hated C/C++ in the first place: “Standard Libraries” that are not standard or consistent across platforms; No standard libraries for Lists, Array Lists, and Hash tables (yes. I’ve used STL. It is very fucked up on Ubuntu and Fedora Core); Threads were not “Standard” either; Endless fighting with header files to make the compiler happy; And finally the nightmare that is USING Gobject. It all amounted to too much work, and almost no progress.

My next attempt was to use D. Which was, and is very promising. It is as fast as C, and includes all the threading and collection support. The problem however was that the Gnu D Compiler was not packaged in Debian, and didn’t include the standard ‘Phobos’ library. That was fine. I fought with it and got it working myself. I was cruising along and creating the Postgresql database back-end when I hit a wall. The wall was that the promise of ABI compatibility with C was not entirely true. It was true for the Cairo wrappers I made, but not for the Postgresql wrappers. So I decided to wait a bit longer and see if a solution presented itself.

A solution came a few months later, after I spent a while learning Ruby on Rails, and gained the wisdom that comes with not focusing on performance and over configuration. I decided to try and implementing everything in Ruby. Simply put: Ruby is amazing. Once I understood the Model View Controller technique. And I mean really understood how it works. Not like the outright lie that is in Wikipedia article. I had an epiphany: If you break your programs up into user interface, logic, and data, it makes everything so much more streamlined. All the problems with coupling and optimization simply vanish. Well it was (and still is) sufficient to say that I would do the entire project in Ruby.

But then I started to notice things. Like the amount of memory even a simple Intuitive Document was using. This wasn’t really a problem. But it would be for small machines like the n800, and would inevitably be a problem when the entire desktop consisted of 6 programs that each use 20 to 30 megabytes of ram. We would have all kinds of issues with paging memory to disk, and the CPU waking up like crazy to manage it all.

I decided to wait a bit and see what the community came up with. This was a long stretch where things like Lowfat, Pyro Desktop, and Online Desktop where being revealed. So it gave me hope that someone else would want to write libraries in a high level language.

Then very recently, I started seeing blog posts about this new GObject friendly, C#-like language called Vala. Like this post where a person makes Gtk MozEmbed wrappers for Vala in a few lines of code. This is how GObject should be used! Since I am using a lot of the Gnome infrastructure under the covers, this might be a very good choice for a library-level language.

So this is the plan so far: Once we get more stable, someone will rewrite the Intuitive Framework to use Vala. Then we will need a way to still use Ruby for the Intuitive Desktop and application part.

Sounds good. Now we just need more contributors!