I think my one proposal would get it back to being more like BeOS without losing the capability of having the always updated list of installed apps, etc.
How hard would it be to get the iconed folders back for in /boot/system/data/deskbar/menu ?
What would be awesome is Tracker being able to store user prefs applied somewhere in config (~/config/settings/Tracker ?) for system folders that are read-only.
One day I’d love to have Haiku application bundles and the ability to organise and run them from anywhere, just like macOS.
Personally I don’t like using the Deskbar menu primarily to launch applications. Currently it is not intuitive to organise the main menu. And the menus are real slow, they don’t draw immediately, show an ugly border before drawing the content (on a VM looks awful), and the default menu location forces unnatural drill direction. It’s one of the aspects that BeOS didn’t do well on. I can very much live without using the main menu for launching software.
You don’t need any of that. Haiku applications (native ones) are a single executable file that contains everything. You can just get this file, put it anywhere, and be done.
But by doing so you lose the ability to update said apps. Which is either a good or a bad thing, depending on the app and its developers.
On Haiku side there is absolutely nothing more we need to do for this to exist. Now you can go bug app developers about it 
That’s great. I got so used to seeing everything as .hpkg files, didn’t even think this would be a thing.
For updating, if someone wrote the Haiku equivalent of Sparkle, and integrated it into BAPI, that would really be wonderful. Why would native Haiku applications be in a repository named “Haikuports” anyway.
QtWebEngine fully fixed without any crashes.
Patches welcome 
No. Native applications may have data files, documentation, add-ons etc. Native BeOS applications also rarely come with only single executable file. Single directory is more realistic.
It is technically possible to set MIME type and application to open for directory. I made some successful experiments with running application with double click on its directory.
X512, that is an excellent way to handle packaging and deploment of an application or service. I would like to see how clicking a directory opens an application. Very cool.
It feels this way is increasing complexity, so it is not necessarily a good thing.
How come?
(dummy text to meet character threshold)
This is how Mac OS works. Applications are directories with the extension “.app”, and contains the actual Mach-O binary at Contents/MacOS/, with resources in Contents/Resources/ and Frameworks (Mac OS speak for shared libraries) at Contents/Frameworks/. This also allows for applications to add some items to an otherwise restricted path, such as a kernel extension in Contents/Extensions/ instead of the system directory /System/Library/Extensions/ or /Library/Extensions/.
This makes me think of how the Haiku packages work, where the package has it’s contents mounted at the appropriate place in the filesystem. Haiku has a mount link, Mac OS allows some internal directory structure to be seen/used by the OS as if it were in the system directories. I prefer the Haiku way, it’s more evident as to what is going on, less “hand-wavvy” if you will.
The application structure makes for an orderly way to deploy applications. The main reason is both localizing the application and organizing the resources so that x86 and M1 can make use of the application. We should at least consider this as a structure for application deployment as well from HaikuDepot.
I agree with this to a certain point. But it makes sense not matter what.
I personally would rather see localizations, resources, etc be embedded in the binary itself, instead of relying on finding and opening files at runtime. I assume that embedding makes the application more portable (copy and run somewhere else), and run faster (resources, etc already in memory). But if there’s to be different binaries per architecture, common resources makes more sense if not going the Fat ELF way.
Landon’s principles and ideas on Fat Elf is where I think Haiku (we) should be. Apple and NeXT have figured this out a long time ago. It just makes sense to create a format that can be used on all platforms: x86, x86_64, ARM and RISC-V.
And I’m happy that Haiku has gotten to the point where it’s time to think about such things. RISC-V boots to a nice GUI and the ARM ports are likely right around the corner.
Fat ELF isn’t magic in the sense that it can run on more platforms. It just is severall targets put into one executable.
I don’t see why I have to download, as a user, an application compiled for architectures I don’t have. This just wastest bandwith… the only real benefactor of this is comercial software imo. (something like apple transitioning arches)
One thing to ease using different arches we could consider is to change the way the package repo uri is formed, perhaps by having only a link to the “root” or version we want and have the package kit automatically add the /arch/ dir at the end. that way the repo uri is the same for all arches to copy and a bit easier to install for users.
Oh, for heaven’s sake, no!
Isn’t this why java (and thus the bytecode) got choosen for android development? and we all know how huge and heavy android today has become.
I don’t think it as the target any wise OS developers should aim to.
FatELF/FatMachO/Universal Binaries have multiple architectures in one file without performance overhead (just some extra disk space used). Whereas Java has bytecode, and just a native interpreter/JIT to “run” the Java bytecode. This isn’t the same thing, though in some ways, has the same end-goal.
Apple uses multi-arch binaries in a very different way.
They only ever support only two architectures at a time. They deprecate one long before they introduce a new one. In that context, the “fat” binaries have a reasonable overhead.
In the case of Haiku, a “fat” binary would contain at least:
This means your executables are 5x bigger and will take 5x longer to compile, to download updates, etc. And really there is no reason to do this. If you want to provide your software in a single-architecture archive, you can put your separate executables for each architecture in that archive. And if you’re afraid that users notice it and delete the ones they don’t need to avoid the disk space waste, you can hide them in a subdirectory and have a small frontend (python or shell script for example) to run the right one.