Maybe a dumb question :
If Haiku is supposed to be supporting the BeOS API, what is the difference between the BeBook, available by default once the system is installed, and the HaikuBook ?
And also is there any reason the HaikuBook is only available online if I’m not mistaken ?
Thanks !
The Haiku Book is our documentation. The Be Book was the documentation of BeOs
The Be Book is licensed under a no-derivitive license (from Access inc iirc), and as such we can’t update it. As currently the Haiku Book does not contain everything relevant that the Be Book contains we are in this awkward position of having both.
The Haiku book covers apis Haiku supports but BeOS doesn’t and also enhancements to apis beos did not have.
For example the layout system.
No one packaged it yet, maybe because it’s still being written and so it’s better to always use the latest version. But if someone submits a patch to package it, I think we’d be happy with that.
You mean, you would like to have it printed?
The BeBook cannot because of licenses1
The HAIKU book could be printed!
No printed version, I was referring to Haiku offline like it’s done on the BeBook
Perhaps someone could generate a pdf and update it every 6 months, or more often if it can be done automatically?
The Haiku Book API documentation is indicated as being generated with doxygen.
However where are the doxygen config files ? (I guess there are required to generate the HTML pages)
docs/user/ directory has Doxyfile and HOWTO.
If printed, the Haiku book would be out of date within a very short time.
Before the internet, Encyclopædia Brittanica was the king of reference. Once Wikipedia was launched, it quickly supplanted the former because it (Wiki) was both free and always up to date.
In my view it would not be a good use of resources to print the Haiku book.
Nobody sugested printing it.
Thanks, that’s what I was looking for 
Some people guessed that “offline” means a paper copy. I think the original author just meant some files on their computer disk, that they can use without Internet access.
I’m a bit sad that using a computer without Internet is becoming an unconceivable thing
BeInc had a really good dev support team, not only was the BeBook designed for print (and the Be Advanced Topics), it had weekly newsletters with code snippets, and the example code was golden.
A lot of the newer Haiku API is missing simple sample codes and tutorials. For instance, I never found (probably my fault) a good tutorial and sample code for the new layout API, hence all my apps today still use custom coded layout. That could be improved.
This is a great opportunity for aspiring new devs to contribute to Haiku, write a simple tutorial for all the classes per kit. There have been some projects in the past, but most of those projects have bit-rotted.
For Haiku-PyAPI users at least, Bemini uses the layout system.
I noticed that, to me this makes it much harder to contribute to e.g Medo, I don’t have a clue what your code is supposed to do and have constant problems with the layout. : )
It’s a bit of an annoyance because I really want Medo to suceed, but last time I tried it it still had too many breaking faults.
It’s a good occasion to check if IA can provide some hints or if it’s generating mistakes.
Can someone indicated if the below is 100% true , partially true or 100% false ?
The Haiku Layout API and the BeOS Layout API differ primarily in their flexibility and how they handle dynamic layouts. The Haiku Layout API was introduced as a more modern and flexible approach to UI layout, addressing the limitations of the original BeOS layout system. Here’s a detailed comparison:
- Introduction of the Layout API
• BeOS Layout API: The original BeOS did not include a true layout management system. Developers had to manually position and resize views within a window. This approach often required significant manual effort to adjust UI components, especially when dealing with window resizing or localization.
• Haiku Layout API: Haiku introduced an advanced layout management system designed to automate positioning and resizing of views based on rules and constraints, making UI design easier and more robust.
- Flexibility and Responsiveness
• BeOS: Without a dedicated layout system, developers used fixed coordinates to place UI elements. This made it difficult to handle dynamic window resizing or to adapt layouts to different screen sizes or languages.
• Haiku: The Layout API provides a responsive design approach, where layouts automatically adjust when windows are resized or contents change. For example:
• BGroupLayout: Organizes views into rows or columns.
• BGridLayout: Provides a grid-based layout for precise alignment.
• BSplitView: Allows adjustable panels with draggable splitters.
- Ease of Use
• BeOS: Developers needed to write custom code to handle resizing (using the SetResizingMode flags) and had to manually manage relationships between views.
• Haiku: The Layout API abstracts these details. Developers define relationships between views declaratively, and the layout engine handles the rest. This significantly reduces boilerplate code.
- Localization and Multilingual Support
• BeOS: Static positioning made it hard to accommodate different string lengths in multiple languages.
• Haiku: The Layout API automatically adjusts to text size changes, making it much easier to support localization.
- Backward Compatibility
• BeOS: Relied on manual layout techniques that were more rigid but remain compatible with older BeOS applications.
• Haiku: Maintains backward compatibility with the BeOS API but adds new features. Old BeOS applications will run on Haiku without requiring changes, but new applications can leverage the Layout API for better design.
- Code Example Comparison
BeOS (Manual Layout):
BButton* button = new BButton(BRect(10, 10, 100, 35), “button”, “Click Me”, new BMessage(‘CLIK’));
button->SetResizingMode(B_FOLLOW_LEFT | B_FOLLOW_TOP);
window->AddChild(button);Haiku (Layout API):
BButton* button = new BButton(“Click Me”, new BMessage(‘CLIK’));
BGroupLayout* layout = new BGroupLayout(B_VERTICAL);
window->SetLayout(layout);
layout->AddView(button);Conclusion
The Haiku Layout API is far more advanced, making it easier to create dynamic, responsive, and localized user interfaces. While the BeOS API is simpler and suitable for fixed layouts, the Haiku API empowers developers to create modern applications with minimal effort.
I’m not reading all that garbage. Can we please keep AI slop off this forum?
The technology doesn’t work because it can’t work for what you are trying to do.
The “AI” can only take the means of words other people have written, and if it can spit this out clearly it used some training data that was dubiously obtained.
The summary is full off nonsense like the BeOS api beeing better for simple and fixed layouts. For one, it isn’t, for another the Haiku layout api is build ontop of what BeOS offered, it is not a replacement by any means.
The haiku Layout api by itself has nothing to do with localization.
Technically the slob doesn’t outright lie, provided you read everything. But if you only check some paragraphs it will mislead you by implying something different that it then later retconns.
Is anything wrong with Laying It All Out, Part 1 | Haiku Project ?
We’re not doing great currently on documentation and examples, sure, but the layout API is one of the very few things we have covered
I’m not going to waste my time checking a thing that you took a few seconds to generate. This is rude, and like asking “can someone check if my shit stinks?”. No thanks.
I understood that these are bad quality results, or at least that rework/cross checkings are required before having something which is corresponding to reality.
My intention was not to bother the community for sure, but the two returns received so far just answered my question, thanks for the honest answers on that.
I saw a case a new comer to the OSS project utilizes to generate API doc and send PRs to that project without saying they used AI for that.
The project has welcoming very high skilled reviewers but they ended to define contribution guideline to prohibit AI generated content.
I personally think AI can be useful for some type of work, but I think AI users have responsibility to the reliability of WHOLE generated contents to contribute to others. Without that it effectively drains collaborators’ time and hurts their trust to you.