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.
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.
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?
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.
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.
“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.
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.
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?
