Saturday, July 19, 2008

A Word of Clarification and Musings about Haiku R2

This morning I got to thinking about the last couple of posts and I realized that it might be easy to misunderstand the officialness (is that a word?) of my efforts. I'm not with Haiku anymore, as I announced last fall, and, as such, nothing that I do at this point can be considered official Haiku code or anything. This is something purely on my own, just like my LibWalter project over at OSDrawer.

For those of you who haven't heard of it -- most people, I'd imagine -- it's a repository of MIT-licensed code which is sorely missing from the BeOS API, like menu items and list items which can have an icon, a font chooser, and other stuff. It also provides a point of access for useful-but-homeless code floating around the Web, like some code that exists for a dropdown combo box that's been around for years. LibWalter It has been done in such a way that when R2 comes around that most, if not all, of the code can be incorporated into the Haiku source tree and give it a nice shot of progress.

These little code projects that I'm currently working on are in the same vein. Too many people have suggested bizarre, impractical, and/or undesirable ideas on the Glass Elevator list. I also fear a "designed by committee" user interface which doesn't really do a decent job of helping someone. No one really seems to have a vision for R2. I do, but I'm in no position to dictate anything, and even if I were, not all of my ideas are necessarily good ones. These screenshots (and the to-be-released-later programs) are an attempt to show that my vision for R2 is good, sensible, practical, and worth putting into place, and because of the way that I'm writing them, it will be possible to try them out on R5, Zeta, or Haiku long before R2 is even a practical target.


  1. for R2 I hope there is more focus on the foundations than the surface on top. We want to attract more OS developers at this stage, because if the users flock to haiku first and the core isn't polished up, we'd have everyone complaining about backwards compatibility down the road.

  2. I wouldn't worry too much about that, really. Most of the paralysis-by-analysis problems stem from the parts of the OS where programming experience are not required. When it comes to user interface design, *everyone* has an opinion. This is part of the reason why discussions went nowhere on the Glass Elevator list and why there were quite a few ideas that sounded cool but had little, if any, practicality.

    The API will have its own discussions, but the existing one can be a very good guide for future ones. If the work of Haiku's developers, particularly its German contingent, is any measure of the future, I'd say we're in very good hands.

  3. my point is that even the good UI ideas may have to wait until all the API's are straightened out. Otherwise a lot of new code will have to be rewritten. I'm concerned about haiku's security, fragility and flexibility.

    I like how firefox was designed to be very extensible from the start. The developers knew that if it was only up to themselves to come up with UI ideas, they'd be outmatched by Microsoft. What they have done is basically outsource UI development with the growing extensions community and some of the most useful ideas go into future firefox versions. The other advantage Firefox has over the original mozilla suite was that you could easily customize the toolbars and rearrange them. For example, on the same row as the menu, I have the nav buttons, the address bar and the search bar. I can nuke any button I want off the toolbar.

    Unfortunately I can only do this on firefox. It would be nice if every native app in the OS had this functionality: people who want minimalism would be happy as well as those who want 5 million buttons and features.