[HN Gopher] Cosmoe: BeOS Class Library on Top of Wayland
___________________________________________________________________
Cosmoe: BeOS Class Library on Top of Wayland
Author : Bogdanp
Score : 157 points
Date : 2025-06-21 09:00 UTC (14 hours ago)
(HTM) web link (cosmoe.org)
(TXT) w3m dump (cosmoe.org)
| pjerem wrote:
| Okay, I love this :)
| leonheld wrote:
| Haiku/BeOS to me is simply _peak_ computer design. This is
| beautiful!
| 90s_dev wrote:
| 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.
| johng wrote:
| I agree, it's such a beautiful OS. The icons are perfect. I
| wish there was a UI like this for MacOS.
| jchw wrote:
| 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.
| mouse_ wrote:
| 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.
| jchw wrote:
| 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.
| snozolli wrote:
| _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.
| jchw wrote:
| 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.
| kosolam wrote:
| 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..
| mouse_ wrote:
| yeah but I don't want to use any of those
| kosolam wrote:
| 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?
| bboygravity wrote:
| Because it looks (way) better than any of the others?
| Disposal8433 wrote:
| Because that API is nice. Why have a Linux when you already
| have Windows?
| kosolam wrote:
| The reason that I started using Linux more than 20 years
| ago wasn't a nice API for sure.
| touggourt wrote:
| 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.
| 0x445442 wrote:
| Go read the following and draw your own comparisons.
|
| https://www.haiku-os.org/legacy-docs/bebook/ClassesAndMethod...
| palmfacehn wrote:
| Fair question. It feels like GTK is entrenched as the default
| these days.
| phkahler wrote:
| 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.
| linguae wrote:
| 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.
| mouse_ wrote:
| Cute!
| jbverschoor wrote:
| 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.
| netdoll wrote:
| 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.
| jbverschoor wrote:
| 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.
| NonEUCitizen wrote:
| Do you own the rights to it? Can it be published on github?
| Thanks.
| jbverschoor wrote:
| I'll see if I can find it :)
| ksherlock wrote:
| You and me both (but for different reasons). Also for
| Flash/ActionScript.
| imchillyb wrote:
| "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.
| cjbgkagh wrote:
| 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.
| Apocryphon wrote:
| 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
| chipotle_coyote wrote:
| 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.)
| dkh wrote:
| Finally, the killer app to checkmate the Wayland naysayers: BeOS
| API implementation
| em-bee wrote:
| 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))
| tialaramex wrote:
| 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.
| em-bee wrote:
| 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.
| tialaramex wrote:
| 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.
| DougMerritt wrote:
| 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.
| kriro wrote:
| For me, one of the lasting contributions of BeOS ist the
| filesystem book: https://archive.org/details/fsdesign
| Gabrys1 wrote:
| I for one, love the wall-switched sockets
| ab5tract wrote:
| 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.
| tialaramex wrote:
| 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.
| bigstrat2003 wrote:
| 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.
| calvinmorrison wrote:
| Right? Why wouldn't you want to expose your mailbox in the same
| file explorer as everything else it's so nifty
| yjftsjthsd-h wrote:
| > 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)
| em-bee wrote:
| funny enough, there is also a haiku theme ;-)
|
| but yes, need something for wayland. but maybe cosmoe helps
| inspire someone to work on that.
| yjftsjthsd-h wrote:
| 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
| chrsw wrote:
| A window manager using this library would be very interesting
| Apocryphon wrote:
| More exciting UI news than Liquid Glass
| tialaramex wrote:
| 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.
| calvinmorrison wrote:
| Haiku is pretty conservative with their versioning. You can
| definitely daily drive it.
| tmountain wrote:
| BeOS is the Latin of operating systems. LOL
| i80and wrote:
| 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.
| dleslie wrote:
| Wifi is as good as FreeBSD, because they share drivers.
|
| But yes, graphics drivers are a problem.
| chrsw wrote:
| 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.
| sockboy wrote:
| 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.
| wmf wrote:
| Linux has supported xattrs for many years; there's no need to
| emulate them.
| jdboyd wrote:
| 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).
| jonhohle wrote:
| For compressed files, HFS+ puts the entire contents in an
| (xattr ne resource fork).
| danans wrote:
| 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.
| tchbnl wrote:
| AFAIK the only thing carried over from Be was Binder (from
| BeIA), which made its way to Android before being completely
| rewritten later on.
| hollandheese wrote:
| >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.
___________________________________________________________________
(page generated 2025-06-21 23:01 UTC)