Haiku Programming: Saving Settings

I think one of the biggest differences between Linux and Haiku is that of having a standard way of doing things. I probably be talking about this difference a lot in the future.

Disclaimer: I’m very new to Haiku programming, so I may make mistakes or not do something the Haiku way. Please correct me if you see any errors. Thank you!

I worked on my RSS feed aggregator a bit over the weekend. I began implementing saved settings.

Linux

There are many ways to save settings in Linux. You can save settings by using GConf (which I just found out is being deprecated in favor of Gsettings). You can use a text file (please make sure to ask xdg where to save it, and not just throw it into the home directory!). Text files can be XML or Lua or old-timey-X-style (whatever that’s called) or made up just for your application. This is probably an over simplified representation of settings files in Linux, but my point is that there’s no single standard way of doing it.

Haiku

The Haiku Human Interface Guidelines explain the standard way of saving settings in Haiku. It involved saving data into a BMessage and then flattening the BMessage into a file. Later, the file can loaded (unflattened) into a BMessage and the settings can be taken out of it.

The Haiku API includes a simple way to get the user’s settings directory:

BPath settingsPath;
find_directory(B_USER_SETTINGS_DIRECTORY, &settingsPath);

The current default user settings directory is “/boot/home/config/settings”. Use the Append method to add a nice name for your settings file:

settingsPath.Append("MyHaikuApplication");

This will make your settings file “/boot/home/config/settings/MyHaikuApplication”.

Messages

BMessage objects are integral to the Haiku API. Here’s a concrete example of what a BMessage looks like. For a BMessage object named “msg”, it has a “what” type (an integer) that can be used to determine the type of BMessage:

msg->what

I don’t use this for saving settings. It has another (very important) purpose that I’ll talk about some other time.

The other thing it has is a whole mess of named data. Here’s a quick example. I’ll save a number into a BMessage:

msg->AddFloat("Pi", 3.141592654);

I can also retrieve it:

float value;
msg->FindFloat("Pi", &value);

As you can see from the documentation, a BMessage can store all sorts of data, include any object or structure. It can even store more that one copy of named data. For example, all of these values will get stored:

msg->AddString("Address", "123 Business Drive");
msg->AddString("Address", "386 Computer Street");
msg->AddString("Address", "7 Internet Superhighway");

They can likewise be pulled out again by using the FindString method. BMessage objects can also store other BMessages. In summary, BMessage objects can allow you to easily store and retrieve data.

Flatten It

To save a BMessage object to file, “flatten” it using the Flatten method. Just send it a pointer to a BFile:

BFile file(settingsPath.Path(), B_CREATE_FILE | B_ERASE_FILE | B_WRITE_ONLY);
if (file.InitCheck() == B_OK)
    msg.Flatten(&file);

Unflattening a file is just as easy:

BFile file(settingsPath.Path(), B_READ_ONLY);
if (file.InitCheck() == B_OK)
    msg.Unflatten(&file);

Changes

Java has a way of serializing objects. This allows you to save an object to a file and then open it again. It sure can be handy, but if you make a change to the class then you can’t open the saved object anymore (as far as I know). The Haiku way of using a BMessage with named values in it doesn’t have this problem. You can always open it and try to read values from it. If the name of a value has changed or is new, then the find will fail and you can simply use a default value. Then, when application quits, you can overwrite the old settings file with the new one.

I WANT PLAIN TEXT FILES RARR!

I’m a Linux user, and I know the benefits of having settings saved in a plain text file. I don’t know of an easy way to extract information from a flattened BMessage besides loading it in an application. Even so, the benefit is that it makes the application responsible for controlling the settings file, even if it means creating a GUI that allows the user to change some settings. Haiku is a desktop operating system. It was designed to be used with a GUI and a mouse. It was also designed to be easy to use. A plain text settings file might be as easy to use as a GUI, but a GUI can allow settinsg to be more discoverable.

An Advanced Case

My RSS feed aggregator has some numerical settings, but it also has more advanced settings. I need to keep track of every “Feed” that the user wants to follow, and every news “Item” in that feed. That’s a list of Item objects inside a list of Feed objects.

I got advice from An Evil Yak, a nice Haiku developer. I decided to create one BMessage for every Feed and one BMessage for every Item. I’ll then add the Item message objects to their corresponding Feed message objects, and all of the Feed message objects to the main settings message object. I’ll then flatten that message to a file.

What Haiku is missing

I recently realized something about the progress of the Haiku operating system. I think it’s ready for a large increase in users, but something is holding it back. That something is an itch. Haiku is missing the right itch to scratch.

There’s an annoying little problem any new operating system must face, whether it’s mobile, desktop, or other: People don’t want to use an operating system that doesn’t have the applications they need, and people won’t create applications until there are people using the operating system. Non-kernel-developers won’t even considering using an operating system until it is far enough along to allow a person to feel like they can do something with it, besides just being a beta tester. Well, I think Haiku is at that point.

Haiku is ready to be used by many people. It’s quite stable and contains many features that many people are looking for in an operating system, such as a nice web browser, chat, and a media player. It comes with great tools for developers. It can mount flash drives, it can be used to download torrents, and it can be used to connect to wifi. It has a pleasing appearance and is very consistant. Of course it’s not ready for everyone, but it certainly is ready to be used by some.

But

Mass adoption isn’t happening. There is talk on the Haiku forums about that being because of infrequent releases and the lack of focus on implementing single imortant pieces of the operating system. I briefly considered the idea that Haiku isn’t being used more because more people don’t know about it, in regards to there being a lack of some sort of marketing. But the more I think about it, the more I don’t think that’s the case.

I enjoy watching people post to the Community Contributions section on the Arch Linux forums. I like watching new applications flourish. Not all of them flourish, but the ones that do seem to have something in common: They were made by someone who was scratching an itch, and a large group of others had the same itch that needed scratching. One of my favorite relatively recent examples is for a fast and powerful file manager, SpaceFM.

I understand that SpaceFM is a relatively small application compared to something as large as an operating system, but even large pieces of software such as GNOME or the Linux kernel started out small. Haiku has been in development for over a decade, but still people aren’t swarming to it. Why is that?

I think the reason is that Haiku is missing an itch.

Microsoft Windows is the most used desktop operating system today. BeOS, which Haiku is based on, was designed to be a nicer, better, easier to use competitor to Windows. It may be, but things have changed a lot since then.

Windows has become easier to use. Mac OS has become much more popular. And people who want the most simplicity in a computing device will use a tablet or just stick with their mobile phone.

People who enjoy writing software and being their own system administrator have the option of using one of the many GNU/Linux distributions or similar operating systems. Haiku would benefit the most if these types of people would start using it and developing for it more. But why would they?

Haiku was designed to be a easy to use desktop operating system. It has one primary API, one GUI toolkit, and one user interface with relatively little customability. Why would a person who uses GNU/Linux with all of the great options and configurations that it provides want to use something so seemingly limiting?

There are people, like me, who love GNU/Linux but are tired of the fragmentation in distributions, user interfaces, GUI toolkits, sound servers, and so on. I wanted an operating system that was cohesive, designed to be easy to use, was free and open source software, and looked good by default. In my search for something with those features I found Haiku. But I think I’m in the minority.

If the needs of free and open source software developers can better be met by GNU/Linux, why would they use and develop software for Haiku? If they don’t, that only leaves professional software developers, and it would take someone who really likes gambling to take a bet on being able to make money by developing their software for Haiku.

If the needs of people who want an easy to use and cohesive operating system can be met by Mac OS and even Windows nowadays, why would they use Haiku? They would if free and open source software was important to them, but that hasn’t really happened with the general public. They want something that just works.

Who is left to use Haiku? People who miss the days of BeOS are interested in Haiku, but those numbers are dwindling. I’m certainly not one of them. I’d never even heard of BeOS until after learning about Haiku.

What can be done to bring software developers to Haiku? I don’t believe there’s really any great technical reasons to use Haiku instead of another modern operating system. Any technical benefit of Haiku, such as pervasive multithreading, is met with a drawback, such as it might not even boot on your current hardware.

I think stressing what Haiku does offer will help find people who are searching for something like Haiku but didn’t really know it. The more people that are informed about Haiku, the higher the chance of finding someone that is interested in using and developing for it.

What are the benefits of using and writing software for Haiku? I’m in the middle of writing my second piece of software for Haiku, and am learning a lot about why someone would want to use and develop for it. I plan on detailing these points over the next many posts. Maybe it’ll spark some interest in the next generation of Haiku developers. Maybe it’ll cause Haiku to jump into the mainstream! Most likely it’ll just allow me a place to blabber on about an operating system I love to blabber on about.

Software on Haiku

I’ve been spending a lot of time using Haiku recently. I had a particularly fun night recently.

I’ve been itching to contribute some nice software to Haiku for a while. Last year I made my first piece of Haiku software: a screensaver of pretty falling leaves. It seemed like a good place to start for me since I like making video games, and screensavers are pretty much just video games without any user input.

http://haikuware.com/directory/view-details/utilities/screensavers/fallleaves

My plan for my next piece of software is to pick a nice library, compile in on Haiku, and then write a native GUI to interact with it. I decided to start by writing an RSS client. It’s coming along slowly but fine.

It’s funny, there’s “no software applications for Haiku”, but at the same time, every time I think I have a great idea to fill in some functionality gap, I find out there already is an application for it in Haiku that works fine. Combine that with the WebPositive web browser and you now have a ton of functionality that’s provided by websites (RSS feed readers, email, document creation…) Probably the biggest application gap I see is that there’s no native word processor, but it’s really hard for me to care. I don’t really use word processors in any operating systems.

Lastly, here’s my usual list of some of the stuff I did in Haiku recently:

  • Log in to my MSN, Yahoo, AIM, and Gmail chat accounts using Caya
  • Download YouTube videos using youtube-dl and watch them using MediaPlayer
  • Listen to music while I program using a playlist in MediaPlayer
  • Host a simple static web page using PoorMan (a “poor man’s” web server)
  • Create a new software project with the Paladin IDE, setup a new project on SourceForge, and sync my work using git
  • Check my email and visit various websites using WebPositive
  • Use BePDF to view some documents that were emailed to me
  • I had some fun trying out and voting on some of the new software releases on Haikuware.

In the past I’ve downloaded files through bittorrent using Transmission, but for some reason it wasn’t working last week. I didn’t really look into it, but I think I was trying to use a crummy seeds.

I plan on spending more time in Vision, the native IRC client, to learn more about software development in Haiku.

Oh, I almost forgot! I resized my partitions and gave myself a new Haiku native partition. So I now have a partition for the Arch Linux operating system, the Haiku operating system, my Linux personal data, and my Haiku personal data. This way I don’t have to fret when upgrading.

Social media and the open Intenet

I successfully avoided the update to the new Facebook “timeline” user interface. Do you know how? I deleted my account!

It was about a year ago that I decided to start trimming my online presence. My main reasons were that I got tired of being the “product” of a business and that it was taking too much of my time. I don’t really miss it.

It took a while to convince myself to go so far as to delete my Facebook account. I pretty much only used it to chat with people (well, only a couple of people) and to let people know that I’d updated my personally-hosted blog. (just use RSS, gosh darn it!) Facebook doesn’t seem to be used by my friends nearly as much as it used to be, so I was pretty much checking it all the time hoping that someone would post something interesting.

Many of my friends have nice open-to-anyone blogs that I can follow anyway. I don’t plan on ever again joining a website that can only be viewed by people who are members.

I’m sure some day I’ll think back on this post and laugh. It’ll be something my future teenage children will tease me about. Facebook will be remembered like we remember MySpace and GeoCities.

One of my favorite things to teach people is that all websites eventually go away. I consider it to be one of the basic laws of the Internet. Don’t become too invested in any one, because some day it’s going to disappear.

On that note, have you made a personal backup of your archlinux.me posts recently?

Backups

Being a good computer user, I make backups. Even so, I’ve been kind of unhappy with my backup process, so I decided to try something a little different.

I’ve been using rsnapshot to backup personal files and settings that I think are important. But I’ve always had this uneasy feeling that something wasn’t quite right with my backups.

There are two important rules regarding backups:

  1. Have one.
  2. Be able to restore it.

That second one is where my concern was. The things I would backup include which Arch Linux packages I use. In theory, it shouldn’t be too hard to setup Arch Linux from a backup to the way I have it now. But I also host a website that uses mysql, and I think I’m backing it up correctly, but, you know, I’ve never tried restoring it, so I’m not really sure. Also, rsnapshot takes way longer to run that I thought it would.

So, I started using dd. My system is a good candidate for it because my primary hard drive and my backup are the exact same model. I was also excited to use it because I got to download and boot into the Arch Linux live CD again, which I haven’t seen in years. Good memories.

So, here’s how I do my new backups:

  1. Boot into the Arch Linux live CD.
  2. Take my external backup drive out of the fireproof box and plug it in.
  3. Confirm the names of the two hard drives.
  4. Use dd.
  5. Wait.
  6. Unplug the drive and put it away.
  7. Relax.

My dd command:

dd if=/dev/INTERNALDRIVEsda of=/dev/EXTERNALDRIVEsdb bs=1M conv=noerror

The benefits of using dd to make an exact copy of my entire hard drive are:

  • I can’t accidentally forget to backup something that I need to setup my computer. My data, my settings, my operating system, and my website all get backed up. Even my Haiku installation gets backed up!
  • If my hard drive fails, I can swap it with my backup drive and be up and running again in a matter of minutes.
  • I’ll have a copy of the lastest Arch Linux installation media lying around, just in case.

Possible drawbacks include:

  • I only have one “copy” of my files, as opposed to one from from last week, one from the week before, and so on. I only ever had one copy, even when I used rsnapshot. I keep a backup mainly in case of a hardware failure, so one copy is all I need.
  • I can’t automate it. That’s ok, because I don’t keep my backup hard drive connected to my computer anyway. Maybe someday when I’m rich and famous I’ll be able to afford an external hard drive and an internal backup hard drive.
  • It’s easier to destroy my computer setup by making a mistake with dd than it is by making a mistake using rsnapshot. Well, be careful!

This has also been my first experience using the dd command. Such power. But, as with any power, it’s important to remember the old saying:

With great power comes great awesomeness.

Arch birthday

Arch Linux turns ten this year.

It doesn’t feel like I’ve been using it for very long. Then I check my pacman log and see the first entry: “installed filesystem”, 2009-11-04.

It’s been almost two and a half years since I’ve installed a Linux distribution! I used to love installing new distros, even if it was just an upgrade. Now I haven’t done that in a long time.

And you know what? I don’t miss it one bit. I love always having the latest software and no need to reinstall anything.

I keep Haiku installed on a separate partition. I’d love to use that as my primary operating system, but I’m afraid it’s not very practical at the moment. Until then, I plan on using and loving Arch Linux for a long time.

Window placement

Window placement is kind of a big deal to me. Out of all the different styles and algorithms for window placement, my favorite for the longest time has been “Random”. Random window placement had a better chance of putting an application window where I wanted it on the screen than any other option – until now.

But first, a bit about window placement:

Microsoft Windows tries to place a window where it was the last time you had it open. I thought this was a good idea at first, until I remembered I use many windows from the same application. Anyway, after that, I don’t know where Windows tries to put new windows.

GNOME 2, FVWM, and many other user interfaces I’ve tried seem to have a thing for the upper left corner of the screen. I hate the upper left corner of the screen! It’s the last place I want a new window is in the upper left corner of the screen, especially when I have a big empty desktop.

I’ve tried a few tiling window managers, but they just weren’t my thing. Oh, well.

Finally, I started using Openbox. I was sad at first, because everything looked great about Openbox except for one thing: the only options for window placement are “Smart” and “Under mouse”. I’m too lazy for “Under mouse” and when a window manager says “Smart” placement I usually don’t find it to be too smart.

I decided to look at the source code for the “Smart” placement, and I was pleasantly surprised! It goes through these logical steps:

  1. If a window knows where it wants to go (like Pidgin instant messenger does) then just put it there.
  2. If there are no windows open, then put it at the center of the screen.
  3. If there are windows open, then find a space where it will fit and center it in that space.
  4. Finally, if it can’t fit anywhere without overlapping another window, place in on the screen randomly.

I love it!

Openbox

I finally gave in and started using the Openbox window manager.

I didn’t want to use it for the longest time for two primary reasons:

  1. It didn’t have any like a task bar, and I couldn’t find any stand alone task bars that I liked.
  2. It’s too popular. So many Arch Linux users use Openbox!

I had an epiphany recently, and that was that I really don’t want anything like a task bar. I use window shading a lot. When I want a window to be hidden, I simply iconify it to nowhere and bring it up again using the root menu. It’s great!

I have conky setup to give my all the heads-up information I need, and a slick theme to make everything look nice.

Openbox supports full compliance with things like full screen applications and changing the screen resolution, which my previous window manager lacked.

I’m happy with Openbox so far, and look forward to using it for a long time.

Software development lessons

  • There should be clear communication about what the problem actually is.

Don’t solve the wrong problem.

  • Solve the problem to meet specifications.
  • Perform test driven design.

If you are unsure of your goals then you’ll never reach them.

  • Use debugging tools.

You can find and fix the problem much faster using debugging tools instead of print commands or, worse, randomly changing things.

  • Don’t repeat yourself.
  • Create a personal collection of software tools and libraries that I wrote.

Learn from the work you do, and keep it with you in order to use it in the future.

  • Write modules with a single responsibility.

If a module tries to do more than one thing, splitting it up will probably make the design easier.

  • Write against interfaces, not classes.

Even if it seems simple and silly to write a simple interface for a single class to use, chances are, in a big project, having it written against an interface will very likely make your life easier in the future.

  • Learn how the entire software system works.

If you can be that person on the project that knows what every part of the system does, you’ll be invaluable.

Steps for being a good programmer

Here are some general pointers I try to remember when writing code. Even though following these guidelines always helps me, I do a poor job at following them. So, I’m hoping that  I’ll follow them better if I write them down here.

Work from the top down

    This can be a nice way to ease into writing . Think about what you want the code to do and write a function name that represents it. (for example, play_game(…)) Then, think about what you want that function to do, and write function names that represent it. (initialize_game(…), update_game(…), draw_game(…)) Keep doing this until you have super simple functions that need to be filled in to make everything work.

    Design good data structures

      This applies to both object oriented design and not. Spend time designing good data structures and objects. Design good relationships between them. I’m not going to describe what makes a data structure good or bad here, but for some reason I can always tell the bad ones when I begin trying to use them in functions.

      Design good simple functions

        Similarly to designing good data structures, design good simple functions. For example, if you have a function name that has the word “and” in it, it may be time to reconsider the design of your code.

        Break the problem down into smaller parts

          This is a more general way of summarizing all of the points above. Writing a new application may be a daunting task. Break the problem down into smaller problems, until the problems that remain are simple and easy to solve.

            If you don’t have the data you need, move the functionality up to a higher level function

            This one’s a little tricky to describe. If you’re working in a function and you seem to need to keep sending more and more data structures as parameters, stop and reconsider if that function is really the right place for all of that logic to happen. Consider moving it up into the function that calls that function instead. This principle seems to help me pretty often.

              Code for the specific application you’re working on

              This is one of the most important points in this list! It’s easy to think it’s a good idea to make your data structures and functions work well for other programs or “future projects”. You know, making your code generic and “reusable”. Well, stop it. The future projects you’re thinking of probably won’t ever get written, and you’ll waste time making your code generic instead of just making it work well for the program you’re working on.