I’m really not sure how any of this, especially the convergence part, could possibly work when Haiku can’t handle multiple monitors properly. This isn’t the case for the “desktop environments” (or, as more commonly referred to, “shells”) of mobile phones.
Better multimonitor support will be a prerequisite for this, along with the following:
- USB-C alternate mode support
- USB-C support in general
- ARM64 support
These can benefit not just a project like this, but Haiku overall. USB-C is becoming more prevalent on PCs too, better multimonitor support is something that Haiku users have wanted for a long time and a motivating factor in driver development, and many are watching the ARM64 Haiku port progress.
Regardless, these do not necessarily mean that UX conceptualisation has to be held back.
On a related note, multimonitor support needs to take into account displays with different DPIs, resolutions, colour spaces, and even orientations. These are all pertinent to both this kind of endeavour and desktop setups alike. These have long been outstanding issues in the Linux space and hopefully Haiku can figure all of them out sooner and better.
1 Like
Made an initial mockup based on this, with a couple changes:
Used a PinePhone template to get an approximation of how things would look like on a real device and possible future target hardware.
System tray, notifications, and quick settings can be accessed from the bottom right corner, system menu on the bottom left, and dock for preferred program shortcuts in the bottom middle. Open applications have tabs in between the UI elements previously mentioned and the app content. The tab area is scrollable if there are enough open apps, but the limited app selection in phone mode shouldn’t make this too cumbersome.
With this in mind, I’m unsure how the user would close apps. Putting close buttons in the tabs would risk the user accidentally closing apps if the screen registers a tap instead of a swipe. Hold to close might be unreliable and could be used instead for rearranging apps if that functionality will be present. Got any ideas?
2 Likes
I’d want the “tab” to be full width for each programm, potentially a drag could then switch to the next or previous application
The tab should be a seperator between the application (above) and the application list/quick settings (possibly notifcations) that could be dragged in, this is also where I’d close apps (in the list).
How would the tray fit into that design?
(also: How did you make that mockup?)
I’ll try to make one when I get home.
Edit: the thing to choose an application could also be just an application in the list, that way you can also have different drawers and arent forced to have everything in one place
1 Like
AFAICT, making a desktop operating system also work as an mobile operating system never works right. It is extremely difficult to design an interface that works with a mouse and a touchscreen at the same time, without making design compromises (giant buttons, anyone?) like GNOME or MS-Windows.
Haiku is one of the few operating systems that have sane user interface design, and it would be a shame to see that change, especially for an irrelevant goal like mobile phone support.
3 Likes
Once again this won’t affect the existing the existing, desktop-oriented design of Haiku and its applications. This is just for a phone mode which will only have a select few apps designed for mobile use. There is a desktop mode for external displays, but it’s just regular Haiku and its apps as they are right now.
If this has to be said a couple more times, then I will.
Edited together some screenshots from a Haiku VM with Deskbar icon size set high and app text hidden, recreated some UI elements, and combined them in Krita. If you want, I could send the project file here.
Not that much. The hardware is different, the constraints are different. Some pieces of code could be shared.
For example, when your phone is “sleeping”, the wifi and 4G is still up and running, so you can receive notifications if someone messages you. The system must be able to wake up in a split second if you receive a phonecall. On a laptop there are no sucq constraint, so you will shut down a lot more things.
This kind of difference can impact pretty much everything in the software stack. So, your options are:
- Make something like Haiku, that focusses on one usecase, and designs things for this specific usecase (desktop/laptop computers)
- Make something like Linux, where there ars thousands of options to tweak everything to your needs
Trying to add phone support to Haiku, or to share resources, would be turning Haiku into something more like Linux. This is why I said I would advocate for a separate project: both projects should be independant and make different decisions. You can’t just stick a new user interface on top of our kernel and libbe. You will need to rethink everything, and you will have conflicts with the way things need to be done on the desktop machines. Maybe some code can be shared, maybe not. But if you start with a mindset of “let’s share as much as possible with Haiku”, you are on the wrong path to make this work. You will be trying to fit a desktop OS onto a phone. It is similar to trying to fit a car engine on a motorcycle. Yes, the technology is similar. Yes, you can make it work and build an engine that sort-of works in both cases, and you can try to sell bad cars and bad motorcycles. But if you understand from the start that motorcycles and cars don’t have the same needs at all, you will probably work on two different designs. And you should probably put two different teams at work on it, otherwise neither project will ever be completed.
2 Likes
That will divert a unreasonable amount of effort and interest for such a small project then. And also misses the point of Haiku, which I think is to focus on a specific usecase, in this case personal computing.
1 Like
nobody suggested doing that…
I think that is pretty Inacurate, my laptop has a WWAN module, Haiku does not support this, but it certainly could, the future of laptops is also moving to ARM64 regardless, whether we like this or not, Haiku will have to deal with this if we want to run on such hardware. For now amd64 seems a safe place to be, but in 5 or 10 years that may not be so
Someone suggested convergence earlier, and I was replying to that.
In all honesty, faster wake from suspend would be beneficial on any portable hardware. And this applies not just with calls, but also text messages and rapidly connecting back to WiFi, Bluetooth, and mobile data.
“faster wake” means keeping a lot more hardware running, so, shorter battery life while in sleep mode.
The point is: it’s a compromise, you have to decide if sleep mode needs to keep e.g. Wifi network up and running, or if you should cut it. On a phone, you clearly want to keep it up. On a laptop, probably not (not at the deepest levels of sleep, at least).
This is how you make improvements for the platforms not shareable between the platforms. Might as well be completely different projects.
Same API allows for porting of apps between them. And it’s not like the whole world is tripping over themselves to support Haiku as it is…
Not true, as phones will also suspend WiFi and Bluetooth and go into deep sleep after a certain duration of inactivity on battery power. Also with baseband, it is the modem firmware that is responsible for keeping it alive in a low-power mode. The modem and the OS send commands to each other and both must know how to handle them. This applies whether the modem is in a phone or laptop.
I agree with Pulkomandy that it is a tradeoff, I don’t think that neccesarily means one should fork anything though, especially if one stated goal is to run haiku in Desktop mode on connected screens, this doesn’t neccesarily mean that all of it has to be in Haikus sourcetree however, I suppose that are questions one can answer later if this effort bears any fruit (as in usable UI construct) at all
1 Like
That’s not the question. Do you want your laptop to keep that module online, and get out of sleep whenever you receive an SMS? Meaning you spin up the CPU and everything? Even if the laptop is packed in your backpack and cannot use its fan to cool down? Sounds like a pretty bad idea to me. But that’s what a phone OS would do.
Yes, the hardware is similar. But the usage and expectations are not.
And that is just an example. The other obvious one is touch-oriented vs mouse-oriented GUIs. And at each and every component of the OS, you have to make different design decisions. If you try to write an OS that does both, you end up with something like Linux. That’s fine, and indeed a lot of computers and phones do run Linux. But this is not at all what we are trying to do with Haiku. We want to be uncompromising by deliberately ignoring many possible use cases.
It’s also what MacOS would do on the new ARM based laptops, it’s not really the problem that you don’t want to on x86, but that you can’t because of the hardware. again, this is all stuff haiku will have to deal with in the future.
I don’t see how writing a gui based on the existing stuff would “be like linux”, either a component gets replaced completely (Desbkar for this case, and ui code for some user facing applications), or it gets minor changes that benefit the desktop too (app_server, driver support), nowhere from this does a want to support endless config options or use cases arise, iOS and MacOS are a good example of how you can split an OS into two variants where one runs on a phone form factor without beeing like linux. (I wouldn’t mind if ‘Maple’ becomes like an iOS to Haiku, i’d also call Haiku like an open source macos) I’d also say Linux is like linux specifically because the people who work on it believe in that model, Haiku doesn’t, so I don’t see any real danger that Haiku becomes like linux because of some UX experiments.
In any case, I don’t see the need to hard fork, that would just make the lives of everyone involved much harder. Especially before any phone specific code is even written.
Anyhow, this is too far offtopic for my taste. I’d rather continue prototyping than going over ideological debates. (It’s sad how every forum topic here seems to go this way lately)
Yes: by making them separate project with separate development teams. Which may or may not happen to share some parts of the code. Which is what I said should be done 
But there’s the additional problem that we clearly don’t have enough people to even deliver the desktop part (we started at roughly the same time as Mac OS X, look what they achieved since, look where we are). So I would prefer to not have the existing team overloaded by an additional goal of getting things to work reasonably well on phones.
How large will that part be? Is it even a good idea to start your OS from Haiku with its 20 year legacy of BeOS stuff? To me it would make more sense to start from scratch, or work from something already designed to run on phones.
Do you really need an app_server so complicated as ours, when all you do is show one fullscreen app, or maybe two apps sharing halves of the screen? On a phone, that’s what you usally get. So, no windowing system is needed. The very idea of BWindow (and it being a separate thread) makes no sense at all there. Server-side drawing may not be the right thing (I don’t know, maybe it is, but that’s something to think about when designing a phone-targetted OS). And so on.
I think in the end, very little code would actually be shared. Maybe I’m wrong. But in any case I would approach the project from that direction: draft the requirements, study the existing phone operating systems, understand what they do well and what they fail at. And then, come up with an architecture for doing things better. I would not approach this by “I have this OS that runs quite well for a largely different use case, how much of it can I reuse?” because that will bend the design towards trying to reuse more things than appropriate, and missing the many places where things really need to be different.
No, when I put my laptop in sleep mode and put it in my backpack, I really don’t want it to wake up. I want it to not use any power until I need it again. It is different when I put my phone in my pocket, quite likely I will need it again very soon.
2 Likes