Haiku on Phones

I don’t really want to make something just for phones, the “plug in a display and you have haiku” usecase is one primary motivation for me, It could be done with a differnet OS, to the detriment of the desktop part, which to me makes little sense. If you “just” emulate Haiku on the screen you would not get the same integration.

So for this effort I would need Haiku one way or the other, if that means some stuff has to be partly replaced that is fine too, this doesn’t mean that the desktop part has to change in any way.

1 Like

the future of laptops is also moving to ARM64 regardless

Obligatory: https://youtu.be/wPrUmViN_5c?t=34

I’ve tried to make a mockup, but the only thing I really learned is that i don’t like krita… It was very difficult to get it to do anything. (And also i picked up my drawing tablet… and the pen was gone, it’s hiding somewhere… )
Hopefully that WonderBrush bug with the selection areas is fixed soonish.

maple-mobile-concept2

Aside from being used to it for digital art, I use Krita since it is available on both Linux and Haiku. I can try to create mockups based on these sometime after New Year’s. What are those peach orange bits supposed to be?

Fingers, anyhow it’s not that important to create relistic movkups, just enough to get across what is ment for the UI design. : )

Given the power of modern Arms phones, if there was a way to daul boot them and use them as portable desktop PCs, that’d be killer. The phone would need hdmi etc type output and usb inout for peripheral device’s.

As to a dedicated phone version, fork for sure

They already do that, except no dual booting needed. You can connect wireless to a TV and get a desktop environment.

This can already be done using USB-C hubs that have those ports, such as what PinePhone Convergence Editions include:
image

And you can use Bluetooth keybord and mouse.

If you wanted to, I think you could actually make this work on Haiku now. The UI framework being proposed is “new” and so you could probably create an app that represents the full screen phone and make apps that talk to that app via some protocol to render their UI on that screen. You might be able to use the App Server, but the way the UI works in the App Server is quite specific to a desktop, and what you want it a bunch of apps talking directly to the main app, and either their UI being rendered by the main app, or the main app displaying their UI after the actual app renders it. It probably would be a new architecture for the UI elements, but the majority of how the app works is probably the same.

If you do that now and POC it, by the time the ARM stuff is working, you would have something to try in the first instance.

Can usb c do 4k video and audio plus peripherals with reasonable latency v??

“usb-c alternate mode” is just displayport, the worst case polling induced latency for most devices is 1ms (not every device asks to poll that often though)

To me it makes more sense to use the layout kit as is, it is good at what it does, if the underlying rendering should be done by something else that would then likely be changed in a lower level. (as in how a BApplication connwcts to the app_server or doesn’t)

The obvious issue with the proposed layouts is that the on screen keyboard will be at the bottom and they create extra distance between keyboard and thumbs. Though the whole UI can slide up to make room for the keyboard but then there are extra UI elements between the app and the keyboard. Having said that, android has the bottom bar that is not too much in the way so it might be OK if it’s small enough, just some food for thought.

It might be an idea to take a look at sailfish as the UI there is quite different to other phone OSs, fully gesture based, and works very well.

Sure, but the App Server makes assumptions about how windows work. In this scenario, you will have a new canvas, new parameters and functionality. This is more like BeIA on top of BeOS than anything else. If you have a root app, like Wagner in BeIA, which presents all of the UI, you would then be able to do exactly what BeIA used to be able to do too… quit the root app and boot Tracker, present a full Desktop UI.

In all of this, I am not trying to say “the root app removes the need for an App Server”, I am saying it compliments it, and that the Phone UI just runs within the confines of the root app. Think of it like the Palm UI from WebOS - the apps are a card deck, and your presentation root app allows you to interact with them. The root app is just a viewer and even the “app loader/app list” is just another app. The apps are true exe files, and when they start they connect to the root app via some protocol and the root app via some protocol displays their UI. The root app handles stuff like “app lifetime” and “pausing” and “resuming” apps and multitasking.

1 Like

Sounds like with proper hardware support and a alternate desktop design this is all very doable.

No need for an alternate desktop design, as a desktop mode can just use what Haiku has right now.

Was thinking the same, too. Phone mode could just be running like BeIA did on the phone screen and Tracker on external screens for desktop mode. Seems like the fastest and cleanest way to go about it, but feel free to correct me on that.

1 Like

Sure. I mean BeIA ran the desktop when you quit Wagner, but it was designed to run on one device with no external display.

The other thing was that BeIA used Binder (OpenBinder) for general app service management. It might be worth looking at that for this project.

Also another feature was that apps could be embedded directly in to the main window (I remember seeing a version of Galaga that was run in the Wagner UI as an embedded element.) So, I guess there are a lot of possibilities, depending on how the UI is put together.

But getting the basics - buttons, text boxes, check boxes and the basic view architecture, that would help a lot to make a POC work.

@nephele suggested in IRC to use test_app_server to simulate a phone screen, presumably for development on a PC. However, could that also be used to present phone mode on a real phone while regular app_server runs in desktop mode on external displays?