Component Models

2:40 am General

I read aaronl‘s 19 Sep 2000 diary entry. In response, I believe that component models are cool. They do not lead to applications with no purpose (it’s hard to respond to that statement, because it seems so ridiculous to me). aaronl‘s assertion that “the only thing it is good for is bloat” seems like the most useful thing to argue against, because it is the most common misperception by people.

Consider federico‘s EOG image viewer. Given an application that wants to display graphics, you have several options. If you know what you’re going to be displaying and know that you’re going to be displaying it every time the application runs, it may be best to use a GtkWidget (or equivalent feature of another GUI toolkit). However, if your application may not necessarily be displaying the graphics (file manager like Nautilus, web browser, etc) then the component is useful. You can load EOG when you need it, and when you’re finished with it you can unload it. This sounds exactly the opposite of “bloat” to me.

Aside from the arguments of bloat and efficiency, aaronl seems to question the usefulness of component models at all. How else would you implement compound document systems except by a component model?

Situation: I am writing a thesis on acoustics and how musicians can apply their knowledge of it to how they perform. I need to be able to write mathematical formulae, and I need to be able to insert short excerpts of music. In a situation like this one, I really need a compound document system to make it look correct. The music staff will need to re-adjust itself if it is moved around and re-sized, so inserting a graphic file like a GIF or PNG is not an ideal solution. Furthermore, I like the idea of being able to compose the entire document from a single application.

Comments are closed.