So, one topic that has been discussed lately is that of saved states across restarts. This is definitely exciting, as it would definitely be a way Haiku could do something others can’t.
My favorite platform outside of Haiku (with anything Gnu/* in third place) is of course the Mac, and starting with Lion, restarting across sessions was first added. Upon restarting, users can choose whether to restart into the last state they had open, as well as for applications (controlled in the General pref pane).
Of course, Lion wasn’t the first. The Apple Lisa had full persistence decades before the Macintosh did, Palm partially had it in its apps (and tried to hold states with the NVFS), and webOS managed to save changes across application launches. And other systems like Microsoft’s NepTune tried to have ‘fast startup’ or resumed states as well.
And in returning to Mac OS, it’s not ‘built-in’ to the system, so it takes a long time to get everything back up for those that have used the auto-save/restart feature on a Mac (especially on a Core 2 Duo). Haiku could have it at the low level.
So, if Haiku could choose to do something like this (beyond the Tracker), and also finally enabled multi-user, this would be a huge leap forward for Haiku. It’d actually be better than sleep mode, provided that it actually worked as intended.
I am not against this idea, especially if apps open in the workspace they were originally in, rather than all being splattered on the active one.
Speaking of which, I thought there was a way in BeOS to tell an application which workspace to start in. Like, always having, say, an Email client loading in workspace 2, even if you started it up in workspace 1. Or maybe it was only certain applications that gave that option? Or I’m just making this up?
Don’t nobody need to go adding something already exists.
What Haiku does not have, however, are multiuser GUI facilities like a login manager, user switcher, etc. I want to implement these.
As for persistence across states - I think I complained about this recently. I am working on one of the tasks marked “easy” in the bug tracker; making LaunchBox restart after reboot. I am accomplishing this by inserting a checkbox in the settings submenu. When checked, it invokes the storage kit to write a symlink to the launch directory. When unchecked, it deletes the symlink. Writing symlinks to the luanch directory is the “Haiku way” to do autostart. Once I have that simple logic figured out (I am not a C++ developer and this is my first foray into using this language), I can request for the ticket to be closed and that restart-on-reboot functionality can be added elsewhere.
It’s awesome you’re contributing to the OS; I look forward to whatever happens with LaunchBox, which I use whenever I use Haiku.
But as far as multiuser, yes, Haiku has the standard tools and is ready on the inside, but everything basically runs in a ‘baron’ or ‘root’-like mode right now, with a single user having full power over whatever is writable. Which isn’t bad – it makes the computer very simple to use and I only wish that the Linuxen behaved as nicely as it does. But it doesn’t have multiple users yet.
The main dream I have though is the hope of having system-wide persistence. Combined with screen dimming/blanking, adding persistence would remove the need for having a sleep mode, really, and it would be really awesome to have.
My exploration into Storage Kit will help with this as well - once I figure out how Storage Kit likes to write files, attributes, etc. I can simply add these functions to the given preference or user application (screen brightness, mouse sensitivities, terminal, tracker, Libre Office, etc.).
Persitence is way harder to implements than just using storage kit :-D. It musst be implemented on haiku side so you need to implement several placed accross Appserverer (for storing App realted information), (Interfacekit for storing window and view stuff) and so on. This is far far from trivial.
So to restore whole apps… from haiku side … this would be a huge task… because you need to store EVERYTHING from the app (best would be a memory dump) and restore it correctly. At the moment Persistence is only possible if the app itself implements on every BWindow and everty BView the Archive and unarchive Methodes (this is used for replicants)… But this also require a special way of implementing and thinking. i guess max 10 % of the apps implemented this features at the moment.
For brigtness control not its not easy a all - it is not just storing a value. You cant just draw stuff darker… ist the background light which is changed,
So you need first a Preferences which is able to talk to a softwarestandard API for backlight control. Then there need a driver for your special Computer which maps this softwareinterface to the HW interface. I am not shure if there is already a sofwareinterface. - a Short search for Brighntness in the haiku git repostiory reveleas that the software hoocks are already there https://github.com/haiku/haiku/search?q=brightness&unscoped_q=brightness
but the driver need to implement this.
This would means only… rewriting every Driver for graphiccards out there so that its able controls the hw backlight.
So a nice read (or a nice document to understand how complex this ist) is: https://www.haiku-os.org/legacy-docs/writing-video-card-drivers/
Plenty graphics driver cannot control the brightness and it should be implemented first.
Then one can think about, how and where to store the brightness settings?
Should the OS let it to the firmware to save it? Not all of them does it.
If the OS stores it, should it be stored on disk or in NVRAM?
When should it applied? At bootloader stage? During driver initialization? During starting the app_server?
If it was implemented on the haiku side to save the AppServer state etc and to reinstate that state when the application returns then an application memory dump might be enough… but you would also need to consider that a piece of software might also need to restore hardware state for a certain piece of hardware in order to resume properly… consider audio playing, libusb or GPU interaction for example. I think you would in addition to the haiku support and memory dumps need applications to explicitly state that they support persistence and provide suspend and resume functions that can be called before suspending and after resuming them.
I think most machines actually support brightness through ACPI so it should really be a question of implementing it once. So I don’t know why it would not work under VESA…
Store it on the OS, let less control on the firmware (they wont have a common api for all manufacturers).
Should be stored on disk so you could remove the missconfigured settings by editing files on the disk (or removing them).
Brightness should be applied as soon as the driver is initialized / active / usable. A brightness control working flawlessly on desktop wont matter if you have a KDL & you’r unable to see your screen.
Else set brightness to visible during booting process, adjust to stored value on desktop initialization.
After working with several kind of hardware (including weird ones like Men Mikro GmbH odometers) in my job, i have less faith in “it complies to standard” and more in “it should comply” in practice.
You can still go the ACPI route and solve specific driver issues (if any).
