Haiku API Bindings
Not logged in

Documentation | Manual: HelloWorld

Chapter 2: Hello, World

We're going to start with the old classic: Hello World. In our case, this means a Window that displays a label containing the text Hello World.

The code we are building here, like all the code in this manual, can be found with the demo code for your language. This one is called HelloWorld.ext.


Every application needs an Application; since we want a Window, we need to pull that in, too; and finally, the class that implements a label is StringView. We start by pulling in those classes.


use HaikuR1::InterfaceKit;
# this will automatically pull in ApplicationKit,
# and there's no need to pull in individual classes


from HaikuR1.ApplicationKit import Application
from HaikuR1.InterfaceKit import Window, StringView


To begin with, we need an Application. Any program that is going to accept user input needs an Application. Without an Application, any Windows will show up briefly on the screen, then simply disappear. The Application allows us to wait for user interaction.

Usually, you are going to want to subclass Application, but this program is simple enough that we can skip that this time, and just use the default Application class.


my $app = HaikuR1::Application->new("application/x.vnd-hab.HelloWorld");


app = Application("application/x.vnd-hab.HelloWorld")

Application takes a single argument, the signature. This is a MIME string with the superclass application. By convention, the subclass should begin with x-vnd, followed by the name of the software producer, then the name of the program. (The hab portion above stands for Haiku API Bindings.)


Next, we need a Window. Even when your program is simple enough that you don't need your own Application subclass, you will almost always need to subclass Window. However, this particular program is so simple that we can skip even that, and just use a standard Window.


my $window = HaikuR1::Window->new(
    frame      => [50, 50, 300, 300],
    title      => "Hello World",
    type       => B_TITLED_WINDOW,
    flags      => B_QUIT_ON_WINDOW_CLOSE,


window = Window(
    frame      = [50, 50, 300, 300],
    title      = "Hello World",
    type       = B_TITLED_WINDOW,
    flags      = B_QUIT_ON_WINDOW_CLOSE,

Let's look at the arguments:

Window.Show() makes the Window visible (they are hidden by default). Additionally, if the Window's message loop has not been started, Show() will start it. (In this simple app, we don't worry about the message loop, so it will just run in the background.)

We've used two Haiku API constants in creating our Window, so we need to go back up to the top of the program and import them.


# since we need the constants, we pull in Window directly
# this will pull in InterfaceKit, which will pull in ApplicationKit
# and there's still no need to pull in the other classes


from HaikuR1.ApplicationKit import Application
use HaikuR1.InterfaceKit import Window, StringView, B_TITLED_WINDOW, B_QUIT_ON_WINDOW_CLOSE


The various display elements that are contained in a Window are called views, and the base class is View. As mentioned above, the view that implements a simple text label is called StringView.


my $string_view = HaikuR1::StringView->new(
    frame        => [10, 10, 100, 25],
    name         => "HelloView",
    text         => "Hello World",


string_view = StringView(
    frame        = [10, 10, 100, 25],
    name         = "HelloView",
    text         = "Hello World",

Once again, the arguments:

Window.AddChild(View) adds the View to the Window. Views are visible by default, so we don't need to do anything to make it visible.

(We do not need to add the Window to the Application because there can only ever be one Application in a program, so every Window automatically belongs to the Application.)

Running the app

Now all our objects are created, we can actually show the Window and wait for user interaction.





Each Window creates its own thread, and the Window's message loop runs in that thread; Window.Show() or Window.Run() will start the thread and return immediately. Application, however, takes over the main thread for its message loop. Application.Run() will not return until the Application quits, which in the case of this simple program will happen when the user closes the Window.

In a more complicated app, we might have to do some cleanup after the Application quits, but in this case, we're done.