System sounds are not “playing” when they should be triggered–except for one, the “Beep” works when triggered.
I am testing Haiku’s personalization capabilities (from a common user perspective). System sounds should just work…
Is there something that I do not see in Preferences to “activate” them?
The Menu was editable in BeOS and Zeta–what is this mess about read-only FS’s!! Really!? We need to have the Menu in one place where users can personalise Haiku as we did previously. The read-only FSs need to go away!!
How can I get rid of the “System” version of the menu so it can only use the “Home” version. Is this “blacklistable”?
I finally figured out the most pressing issue regarding themes by copying the themes from “System” to “Home” so I can use and update them. (Again the read-ony FSs … can you make them read-writable on-the-fly like how the package manager does it to performs its updates when installing software?)
So my question is this–is there a theme builder software? I am unable to locate one for Haiku.
The system side is not editable, thats good. There is a way to costomize the menu by hand. But you need to update it past every new Installation. Here we need a automatation from the system.
Thats ok by the main idea, because the user can install by hand using the non-packaged folder in home. If there is a bug in the theme manager, you should do a bug report to it.
What “themes” are you working with?
The only theme related software I know is ThemeManager. I suppose its dev should have the pre-configured themes moved to ~/config/settings/UIThemes or elsewhere in the home hierarchy on installation, if users are supposed to be allowed to change them.
Packages are virtually mounted when they are installed, they’ll always be non-writable. You can search the forums and mailing lists of the better part of the last decade for continuous critique and explanations…
The dev wiki has more infos (moved somewhere some time back so I cannot find it anymore, marked “obsolete” the wiki, but should still be valid… sigh).
This would make only sense if this function is for the admin only. But it is not possible, because all packages are virtual, that means they are hanging in by startup the system, so you does not can copy things there without installing it. There are the non-packaged folders to install by hand.
The Bug #1902 addresses only one of the 16 possible sound assignments.
I created a new bug ticket at https://dev.haiku-os.org/ticket/15295#ticket to address the system sounds not being played/activated/triggered when a one of 15 trigger events occur.
Haiku is not a Mac OS…system directory should be open for updates,etc.
Moreover, it is amazing how you all developed and deployed a unique ‘multitenancy concept with pluggables’ paradigm. I do not think any group has done that at this OS level. Pretty cool really!!
From my reading so far, this is how I understand what is going on.
--------
| H {=|===========}
| a { Haiku OS Virtual File System } <== LOADED FROM HaikuOS.hpkg
| i {=|===========}
| k |
| u {=|===========}
| { Home VFS } <== LOADED FROM Home.hpkg
| B {=|===========}
| O |
| O {=|===========}
| T { Tracker VFS } <== LOADED FROM Tracker.hpkg
| {=|===========}
| |
| {=|===========}
| { Deskbar VFS } <== LOADED FROM Deskbar.hpkg
| {=|===========}
| |
| ... | <== many other hpkg's
|vvvvvv|
All these ‘pluggable’ VFS’s should be ‘live’ (including SYSTEM) and not ‘read-only’ as in a real virtual environment.
Haiku should have active system processor running when the OS is open/operating so that:
“plugs-in” these VFS’s into the OS system on startup [,which it currently does]
monitors changes to each VFS (whatever it may be)
backups the VFS prior to saving “updated” VFS [introduce a version control process for possible recovery]
saves a “new” VFS with the user’s changes on shutdown
Why? Because from an UX experience for new potential Haiku converts and Haikuphiles alike, no Haiku user should ever experience or see the dreaded “read-only filesystem” message!
It all should just work and be transparent “under the hood”, per se.
That way…we can easily personalize/customize/use Haiku as we see fit as with the other OS’es.
The ThemeManager is probably what I was looking for. After playing with it more, I was able to capture the screenshot:
As I worked through all the other panels, I realized it is an aggregator of many options and assigments. So if I use graphics and sound applications to create new sounds and backgrounds, I can incorporate these new pieces via the Theme Manager into new theme(s):
I would like to create new screensavers that would be specific for my themes…so I bet that would be a learning experience in how to do those.
Well, the ‘menu-sorter’ app was not available for me to download–probably only 32-bit(?). Anyway, I used the article you cited and it took some time but I now have what I wanted:
It is OK if you don’t like how the things are currently, but do not reason like “THEY should not see this.” is not the correct way. Explain why YOU want to change it.
THEY probably already met with the read-only FS using other OS, for example on macOS the system files also read only, and one need to boot it in recovery mode to disable SIP. Would you recommend for a user to disable SIP?
If they want to change system files, they doing either something from muscle memory or they doing something advanced thing, and for this a standardized way already exists in Haiku.
Study the user guide for more information.
This guy’s confusion is just another example of why non-packaged doesn’t make sense… it’s completely user unfriendly. And from what I understand is just an arbitrary bad design decision.
I does not think so. Non-packaged is for backward compatiblity and testing. No one wants to create every time testing something, to build a package before. And a user use HaikuDepot to install things if he was good informed by starting haiku first time. He does not come in contact with non-packaged in any way. Its only a problem by old beos users who does not want to go the new way. Old hardliner Who sah “I have installed everything in every position in the past, and now I want it do again”.
On the specific point of editing menus we definitely need to create a better solution.
In general, there should be no reason a user needs to edit a system file or place something into non-packaged. Ideally the average user will not even know they exist.
I am definitely guilty of being a long-time BeOS and Zeta user.
The last time I evaluated Haiku that I reported on was Alpha 1; however, I did not evaluate A2, A3 & A4 because I could never install it cleanly on any of my systems that I had at the time–nor did I have the extra time to do deep dives then either. But for the Beta 1, I bought new hardware that I predicted would be favorable for a clean install–I was lucky. I only had sound issues, which seems to be a common issue.
My points of contention are as I stated throughout this discourse. The average new user should never have to face and to resolve system related personalization/customization challenges that should be simple or one-click events: i.e. drag-and-drop personal fonts into system font area, set-up system menus, update/create system themes, assign system sounds, and so forth because of limitations of ‘read-only’ file systems. I understand that many current Haikuphiles have learned to live with it since they have “grown up” with the many changes throughout the years, but that does not make it right either (from a basic user experience perspective).
But as lelldorin, extrowerk, and diver have previously stated their counter-points, which I do not really disagree with them. I am a professional database engineer and system administrator–so I undertand their points about protecting the system resources. However, the ‘read-only filesystems’ that prevent the simple user activities will not meet the new user expectations of a great OS! It will only frustrate them and they will simply not become a Haiku convert because of a bad first impression!!
Don’t get me wrong–I love what has been produced and I have a very good Haiku system to be a daily user now!! I REALLY have missed my BeOS/Zeta systems, which I lost everything when I lived overseas.
So I will be an active participant henceforth…by testing and evaluating and so forth. I cannot wait to see what Beta 2 will deliver…
Unfortunately it is a problem that didn’t really exist before and it will crop up again in other areas… the fact that the packages are not overlaid onto a writable FS makes that pretty much inevitable.
I intend at some point go go back and thoroughly read through the discussion of all this… since I know it’s been talked about at length. And I hope I haven’t missed some serious flaw in my thoughts on this. I think the problem was that if you have BeFS and overlay packages on it… you would accumulate cruft in BeFS over time as writable files got strewn around over time? Obviously making most of the FS R/O fixed that issue but causes new ones also.
This would be the case you have BeFS with highest priority, and overlay with lower priority with packages shining through instead of the other way around. You’d potentially accumulate files that shouldn’t be in BeFS preventing updated packaged files from showing up.
The other alternative is all BeFS paths say the same, but new paths are added to be checked in read only ./packaged folders that you can’t mess up. But the rest of the usual paths are complete writable as before. config files would be shine through to the normal paths though since you would want to be able to edit them or delete the BeFS copy and let the RO package file shine through.
The latter solution would mean you have much fewer shine through files… and still retain normal folder writability and hierarchy albeit with packaged folders now.
I think implementing it that way would still remain fairly orthogonal to the versioning feature yes? And not be terribly different from how it is now, mostly an organizational change doable from haikuports.
The other day I replied to a previous response as I began to understand what everyone was talking about where I stated:
I am still learning how things function under the hood. I agree with your thoughts for possible improvement…Haiku can only get better. Too bad that I am not a kernal specialist and virtualization programmer…as I still do not quite undertand the full implementation of what is really happening “underneath the Haiku hood” yet though I think I see it from a high-level. Ingenious stuff!!
I actually found one use case for non-packaged folder. Basically I’m using LaunchBox as a desktop “widget”, but since its panels are essentially windows and not replicants, I have to run LaunchBox at system startup. This adds a deskbar entry for it, which I don’t need because the panels are always on my desktop, so it’s just wasting my deskbar space. The problem is solved by ticking “Background app” in Filetype add-on, but this attribute is not preserved due to the executable being in read-only location. I had to put LaunchBox binary into non-packaged just to hide it from deskbar I am totally fine with it though (come on guys, everyone should be able to read the user guide)
I am totally fine with it though (come on guys, everyone should be able to read the user guide) 