Cosmoe: BeOS Class Library on Top of Wayland | Hacker News Reader

Cosmoe: BeOS Class Library on Top of Wayland

cosmoe.org

180 pointsBogdanp71 comments

Haiku/BeOS to me is simply peak computer design. This is beautiful!

It gives me so much nostalgia for certain Trillian 0.7x skins that I can't put my finger on. Skinning apps was one of the things I wanted to bring back.

I agree, it's such a beautiful OS. The icons are perfect. I wish there was a UI like this for MacOS.

Emulating extended attributes for a filesystem is a fascinating approach. It can significantly streamline lightweight OS customization without needing a full port of the filesystem driver. Has anyone experimented with this in open-source projects? Would love to hear about practical results or challenges.

Linux has supported xattrs for many years; there's no need to emulate them.

Linux's xattrs appear to only be an array of bytes, while Haiku's extended attributes are typed (string, mime, int, llong, float, double, bool, icon, or raw). This means a compatibility layer is probably needed to handle encoding types into the value of the xattr. Xattr(7) says there is a limit of 64kb for the value. Some haiku programs allegedly use more, but i dont have an example handy. Further, specific file systems may impose additional restrictions. For instance ext4 requires all xattrs to fit in a single file system block (assuming that the man page I'm reading is not out of date).

For compressed files, HFS+ puts the entire contents in an (xattr né resource fork).

macOS resource forks values are "file-like" with position-based "block" read/write, Linux xattrs is a key-value map with atomic get/set operations on the whole value only.

Finally, the killer app to checkmate the Wayland naysayers: BeOS API implementation

from BeOS/Haiku i am actually most interested in two things:

the way windows are styled/handled. so i'd like to see a BeOS styled compositor/window manager.

the database like filesystem, and of course gui and commandline tools to use it. (can the filesystem features be emulated with extended attributes, or is a full port of the filesystem driver needed to get a filesystem with the same features? (i am not looking for compatibility, just the feature set))

BeOS only actually had a "database like filesystem" in very early versions, so most likely you're thinking of BeFS, the filesystem used in BeOS R5 (which was given away free) and in Haiku.

But all BeFS has in the way of being "database like" is arbitrary named & typed btree indices, chosen by the owner. You can have a btree of filenames, a btree of "sent by" email addresses, maybe one of file types for example. If enabled (which is the default) you pay for this feature with a significant perf overhead on operations because those tree indices must be updated, but if it's disabled (common for disks with lots of small files) you lose the facilities enabled by having such an index.

Compared to full text indexing, which was also popular on some systems at about the same time, this doesn't produce very impressive results, yet you're paying for it everywhere. No surprise then that even the text indexing remains a niche feature, I know people who care about it a lot and others who've never been interested.

It's probably one of those niche features like wall switches for floor lamps (a socket is run off the lighting circuit and switched just like ceiling lights, but a floor lamp is plugged into that socket). A few people love it, most people aren't bothered, so, it's usually not done.

the performance issue sounds like an implementation/design problem rather than a feature issue. most linux filesystems have extended attributes, and i am sure feature wise, the fields could just be mapped onto those.

indices are a standard feature in databases, and yes, they can slow down some queries while speeding up others, so you should use them judiciously. maybe BFS has an issue there, but that does not negate the concept.

practically speaking, what i want is a gui filemanager that lets me set arbitrary keys and values on files, display them and filter for them. indexing them is not required.

btw: UK style power sockets all have individual switches to turn them off or on. maybe elsewhere people aren't bothered because they are not used to the idea.

I live in the UK, so I'm aware our power sockets have switches. However, if I walk into a darkened room I certainly don't want to crawl around in the dark looking for a switch - so better that (as I believe a friend's home has in some of their guest bedrooms when I had reason to visit) there's an ordinary light switch, near the entrance door at a good height - to activate the distant socket.

Since you live in the UK you may also be aware that, unlike ordinary appliances, smaller low power (5 amp) connectors are authorised for lighting, so in that particular house because of its age the floor lamps literally can't plug into a conventional socket, the plugs are the wrong size, this has the further advantage that you can't accidentally plug an appliance such as a vacuum cleaner or television into a socket controlled from a light switch.

Since the topic arose, FWIW, here in the U.S. it's common to have one power socket in a room (e.g. living room, bedroom) controlled by wall switch, and multiple other power outlets lacking such a switch.

I'm not in the industry, but I think the idea is that, in the absence of built-in lighting, one should be able to add lamps to a room that can be turned on/off by a handy power switch next to the room's entrance.

For me, one of the lasting contributions of BeOS ist the filesystem book: https://archive.org/details/fsdesign

Any cherished nuggets of wisdom to share from it for those of us too lazy to read it?

I for one, love the wall-switched sockets

I don’t recall any real sluggishness with BeOS, in any category.

Come to think of it, I haven’t used an OS that could match the accuracy, speed, or most importantly utility of BeOS’ active queries since 2001.

Yes there are UI and UX choices which make it feel less sluggish, which is an important thing to do and e.g. Windows could certainly stand to improve there.

But in terms of wallclock time "less sluggish" just translates to it takes longer but you don't notice as much. Maybe the file copy takes 18 seconds but feels butter smooth, in contrast to this alternative where it took 14 seconds but wasn't nice - so for 4 extra seconds you get buttery smooth delay. Those seconds add up.

It may be a US/UK difference, but wall switches for floor lights are actually quite common in my experience. Most houses I've been in have had them. Of course I could just be getting uncommonly lucky to find so many.

Several important details are wrong in your comment.

> BeOS R5 (which was given away free)

No, BeOS 5 Professional was paid proprietary software. However, there was a free demo version, BeOS 5 Personal.

https://arstechnica.com/information-technology/2000/06/beosr...

$69.95

> full text indexing, which was also popular on some systems at about the same time

[[citation needed]]

I think this is incorrect. The first mainstream OS with full-text indexing and searching was Mac OS X 10.4 "Tiger" launched in 2005, 5 years of fast-paced development and tech change after BeOS 5.

https://en.wikipedia.org/wiki/Mac_OS_X_Tiger

The feature was called Spotlight.

https://en.wikipedia.org/wiki/Spotlight_(Apple)

"Tiger" was $129.95 and needed a PowerPC G3, 256MB of RAM and 3GB of disk.

A G3 meant minimum of 233MHz.

BeOS 5 was half the price, and needed 32MB of RAM, 150MB of disk, and a PowerPC 603 or better -- meaning a starting speed of 75MHz.

https://asleson.org/public/mirrors/www.be.com/support/guides...

You are not comparing like with like here.

Windows Indexing Service was bundled by default with Windows 2000 and integrated in search interface (it was available before as option for NT 4.0).

The main difference is that it was way less known, and early on it required considerable time to process things because of less powerful computers being norm.

All right, valid point.

It was intended for indexing IIS websites, although by W2K it could handle MS Office files. Was it directly visible from Explorer? The first Windows I personally remember with file search in the desktop – for instance, in the Start menu – was Vista, which came out in 2006 and which has a totally different indexing and search tool which replaced Indexing Service.

Yes, the default windows search boxes utilized indexing service if it was enabled. Windows 2000 also shipped with a ton of IFilter modules to enable indexing of various files. It was also first shipped for indexing IIS, but originally was part of Cairo as whole-OS indexer.

Vista introduced "next generation" implementation and used it by default, though you could still use the old one. IFilter remained the same for both. What really changed was how it was more visible and less performance impacting with newer computers - most people I knew disabled indexing because performance and there was no real culture of using built-in windows search.

Right? Why wouldn't you want to expose your mailbox in the same file explorer as everything else it's so nifty

> the way windows are styled/handled. so i'd like to see a BeOS styled compositor/window manager.

pekwm with the right theme looks close enough and tabs windows together, which IMHO is the biggest feature: https://www.pekwm.se/themes/benu.html

(Of course, that's an X window manager, so AFAIK it can't be combined with this)

funny enough, there is also a haiku theme ;-)

but yes, need something for wayland. but maybe cosmoe helps inspire someone to work on that.

Hah, so there is! ( https://www.pekwm.se/themes/haiku.html if anyone else wants it) Actually I like the look of that better too

A window manager using this library would be very interesting

https://gitlab.com/metsatron/BeOS-r5-XFWM

More exciting UI news than Liquid Glass

Interesting.. back in the early ‘00, I implemented the BeOS api on top of the win32 api. Naive me thought that would make people adopt programming for BeOS and in turn would make it a popular OS.

Was this an independent hobbyist reimplementation? Gobe did something similar in order to port their productivity suite (sorely missed) from BeOS over to Windows and Linux.

Had juist a hobby. Never released it, but it worked quite well. It was remarkably easy to add the events and controls etc after I got the initial version working.

Do you own the rights to it? Can it be published on github? Thanks.

I’ll see if I can find it :)

You and me both (but for different reasons). Also for Flash/ActionScript.

Now this looks interesting. I am not familiar with the BeOS APIs, but the UI design is very pleasing.

One thing I don't see mentioned anywhere including the plans is accessibility though. Not having basic accessibility support would be a serious issue, so I'm hoping it is either already there and just not mentioned or at least planned in some way.

In a very real way, Windows XP was more accessible than anything made since, due to it being more friendly to hacks. There's a reason you see so many disabled people who refuse to abandon their ancient setups.

Smaller, simpler, more hackable software is inherently more accessible.

Okay. But in practice you do still need basic keyboard control and screen reader support. If Windows XP didn't have robust support for that I suspect it would be a very different story, but it did.

Edit: Of all the comments to disagree with, I am blown away that this is today's. You guys desperately need to explain what you're disagreeing with here. Seriously, leave a reply.

and screen reader support

If you look at how classic Win32 applications are constructed, I don't think you need anywhere near the support for screen reader software that you do with modern applications. All of the elements of a dialog box, for example, are constructed from a standard set of controls, and can be interrogated programmatically for their text.

I don't know anything about the internals of BeOS software, but I would bet that it's closer to Win32 in this regard than it is to more modern UI systems.

Just to be completely clear I'm not suggesting the BeOS APIs are insufficient to implement robust screen reader support, just that Windows XP actually did implement it, from the ground up, and integrated it into Win32. I would love it if Cosmoe (and in general, more niche toolkits) would do this, too. It's non-trivial work so it's not like I expect it, but it makes using this toolkit for real programs intended for a general audience much more reasonable.

“There are several sample applications included which demonstrate what it is capable of.”

This was the mantra of BeOs. Here’s a technology preview. Watch videos on a cube, now a sphere!

The OS was sold as a technology preview that was easy and accessible and the users only needed to wait for developers…

…that never showed up.

Similar occurrence with Microsoft phones and lack of developers. Pebble watch and lack of developers…

What these projects all lack are meaningful engagement instead of a few ‘oh wow’ moments.

Microsoft Phone was a giant pile of unforced errors on Microsoft’s part, it wasn’t the developers fault, that thing was a POS that never got better.

Microsoft making it difficult for users to run BeOS didn’t make things easy.

> The Flora Prius was preinstalled with both Microsoft Windows 98 as well as BeOS. It did not, however, have a dual-boot option as Microsoft reminded Hitachi of the terms of the Windows OEM license.[4] In effect, two thirds of the hard drive was hidden from the end-user, and a series of complicated manipulations was necessary to activate the BeOS partition.[5]

https://en.wikipedia.org/wiki/Hitachi_Flora_Prius

I mean, I get that argument, but I actually ran BeOS full-time for over a year. It had a great Works-style office suite (GoBe Productive) written by the people who wrote ClarisWorks, a few good graphics programs including an amazing competitor to Macromedia Fireworks (e-Picture), a solid BBEdit-like programming editor (Pe), a few music programs that did things that I’m not sure I’ve seen other systems do to this day like SoundPlay’s wacky ability to act as a mixer, with speed control, between multiple MP3 files or ObjektSynth’s…object-oriented synthesizer (it’s very hard to describe). There was a stage control system for live performances whose name I forget now—the company is still around, as far as I know—that was used, running on BeOS, for several Broadway shows and Circue de Soleil installations. And an animation program that started on BeOS, Moho, is still around today.

The engagement was certainly starting, and I think there’s a chance—a small one, to be sure, but a chance—that if Be, Inc., hadn’t clearly decided that carving out a comfortable niche just wasn’t enough, BeOS might have succeeded. (Instead they decided to go all-in on “Internet Appliances,” which ended up dealing them the death blow rather than a big success. Ironically, I think that market effectively succeeded a decade later, but in the form of the iPad.)

One thing that's fun about this is that BeOS isn't going anywhere.

If you decided to do this for, say, Windows, Microsoft is going to release a new Windows version with new stuff you can't do and too bad.

But BeOS itself is dead, and the Haiku project (to basically make BeOS again, once named "OpenBeOS") is about a quarter of a century old yet seems barely closer to releasing anything. A lethargic snail could sleep walk to the finish before Haiku ships version 2.

Haiku is pretty conservative with their versioning. You can definitely daily drive it.

BeOS is the Latin of operating systems. LOL

Haiku is in genuinely good shape. I contributed some code to it years and years ago and even back then it ran nicely even on bare metal.

About the only thing I think you miss out on is GPU acceleration and maybe wifi? I haven't kept up with the current state.

Wifi is as good as FreeBSD, because they share drivers.

But yes, graphics drivers are a problem.

That's a shame because the the Haiku code base is relatively easy to get into. It's not overly complicated, it's consistent, it doesn't have layers of different styles from different eras and origins, and so on. It's C++ but it doesn't use last C++ feature to show off how clever you can be. At least, I'm pretty sure that's still the case because it's been years since I looked at it. I remember being surprised about how easy it was to form a metal model of the design and a model of the design-behavior interaction.

BeOS sold to Palm. Palm developed WebOS and sold that to LG. I wonder if any of BeOS ended up on my current WebOS powered LG TV. I bet someone here knows.

AFAIK the only thing carried over from Be was Binder (from BeIA), which made its way to Android before being completely rewritten later on.

A lot of concepts from BeOS survive in Android, to the point that some APIs look pretty much identical at low level.

>I wonder if any of BeOS ended up on my current WebOS powered LG TV. I bet someone here knows.

None at all. Palm split into two companies in 2003, PalmOne and PalmSource. PalmOne handled the hardware and PalmSource handled the software. BeOS went with PalmSource.

PalmOne eventually bought the full rights to the Palm trademark from PalmSource in 2005 and switched back to being Palm. This is the company that made WebOS and got bought by HP.

PalmSource got bought by ACCESS (the company that made NetFront, one of the early mobile webbrowsers) and the rights to BeOS went to them in the sale.

> ACCESS (the company that made NetFront, one of the early mobile webbrowsers)

I think that Access provides the web browser in the Kindle. That's probably the most widely-seen product by the most people.

It also tried to made a multitasking multimedia-capable PalmOS, PalmOS 6 "Cobalt."

https://www.palmsource.com/palmos/cobalt.html

My submission of it here got some discussion 9mth ago:

https://news.ycombinator.com/item?id=41522434

What are the practical benefits of this library? We have gtk,qt,fltk,wx, and a long list of others some cross platform some not..

yeah but I don't want to use any of those

Got it. The practical benefit is that you have a library that you want to use, now? Good for you, sir. But seriously, why have another native c++ gui library?

Because it looks (way) better than any of the others?

Because that API is nice. Why have a Linux when you already have Windows?

The reason that I started using Linux more than 20 years ago wasn’t a nice API for sure.

Because his son started studying programming, so he resurrected this 20 years old project. Did you read the History page on Cosmoe website ? You should (https://cosmoe.org/history.html)

Ton of projects exists, ton of cars, ton of bicycles, ton of shoes, ton of pens, ton of keyboards, mices and screens... each of them are just another one and there is no real benefit to chose one rather than another (price excepted). They exist, because someone wanted to try someting or do something. Humans do things that way.

If the current UI libraries are enough, then why are people diving for Electron slop instead of using them? Seems like there's room for improvement here if nobody wants to touch any of them.

Go read the following and draw your own comparisons.

https://www.haiku-os.org/legacy-docs/bebook/ClassesAndMethod...

Fair question. It feels like GTK is entrenched as the default these days.

If you want cross platform and bindings for many languages (a universal gui toolkit) you land on GTK. QT is close, but it's not just a gui toolkit, it's C++, and there's a bit of commercial/OSS tension. GTK has its issues, but it's the most universal one.

1. Cosmoe is a native C++ library, which may be of interest for C++ programmers.

2. Cosmoe is under the MIT license, which may be of interest for those wanting pure MIT/BSD-licensed solutions, as well as for those who want to use a C++-native toolkit but are concerned that their use cases may subject them to having to pay for a commercial Qt license.

3. BeOS appeal.

Okay, I love this :)

Cute!

Reply on news.ycombinator.com