How can I rewrite (replace) the file if this folder has become “read only”?
If I create a file in /boot/system/bin (from another Haiku), then this file is not visible not in the Tracker, not in the terminal. But visible in the search 
There are dependencies for a good reason. As part of the team handling support for Haiku, I do not want to spend hours investigating “app X does not start” bugreports only to find the user has removed some system lib or package. Dependencies avoid this.
Before we had package management, I would install a new lib, make my system unbootable, and then spend hours trying to fix things (downloading a nightly, trying to fix my mess, then giving up and reinstalling everything and spending hours restoring my settings).
Now, I can do it with blacklist + copy the new file in non-packaged (again, if non-packaged does not work for something, it’s a bug, report it and we will fix). Ideally, you don’t even need to blacklist, having a file with the same name in non-packaged should be enough to override the one in packages (but this does not work perfectly yet - it works for libs, but not for add-ons).
Let’s get the kernel running first.
You can create packages outside haikuports with the “package” tool. There are even several repos offering packages made this way, and I hope there will be more of these in the future. Haikuports is great because we can capitalize on the recipes and make sure we can rebuild and update the packages. It does not remove the possibility of hand-made packages, I even added support in cpack/cmake for generating HPKGs in a portable way.
cp file.hpkg /system/packages
or
make install PREFIX=/system/non-packaged
4 Likes
I understand, this thing is for power users, but maybe you also should check the user guide.
Why would you put anything in that folder? Why not in /system/non-packaged/bin or home/config/non-packaged/bin? Or you can add a folder to your $PATH env var.
I think for almost all your problems there are tested workarounds, described in the user guide.
2 Likes
As was said, you can use the package tool. You can even decompress the haiku package, edit the manifest file to remove the dependencies you don’t want, and recreate it from the files, and replace it in /system/packages/. Of course “no warranty expressed or implied…” 
Well, for most things when I test I just blacklist the file and copy the modified to ~/config/non-packaged/… works for most things. And I just have to disable user addons in case it won’t boot anymore, unlike if I replace a system file. It’s actually simpler, you just need to get used to it.
Well, there is a crazy person who wants to port Haiku to Atari Falcon with much less RAM. So we’ll get there anyway.
Yes it can. I actually have several old copies of VLC on another partition, and I can just right-click, “Open With” → /Data/…/vlc-0.xx and it just works. It’s just not known by the packaging system so it won’t fix them when they break because of binary incompatibilities (which we should fix anyway but still). But for regular software there is no point to it.
Yeah, what he said!
Really, most points are moot.
2 Likes
HakiNS decor - Just another decorator in the style of NEXTStep (more precisely WindowMaker).
Download HakiNSdecor 32bit only
64bit - coming soon
4 Likes
Hello @s40in! I really like your new decors. I just want to notice a small glitch that I found:
In specific kind of windows, like the used for the HaikuDepot screenshoots, the color border doesn’t show correctly. There is an example (CDE decor):
The same window, with the default decor:
I found the same glitch in the another two decors too.
Thanks for the feedback. I corrected the error.
I have now made one package with all decors. It’s easier for me )
1 Like
Small update HAKILO Decorator Pack v.1.0.2
- New HakiWarp4Decor
Hakilo DecorsPack 1.0.2 32bit HPKG
Hakilo DecorsPack 1.0.2 64bit HPKG
2 Likes
Do you intend contributing those to the source tree ? 
4 Likes
Decorator should maybe be outside the main repository? On the topic, is there a good documentation on writing your own decorators?
1 Like
Not necessarily, we already have some.
Having them in the official tree means they have better chance on being updated if the interface changes, but it’s harder to change them yourself if you don’t have commit access.
2 Likes
IMHO the only Decorators that should be in source tree should be the HaikuDecorator (aka DefaultDecorator) and BeDecorator. The rest should be packages that you can install from HaikuDepot. MacDecorator, WinDecorator, etc. We already have the capability to install and uninstall decorators via a script so creating a package should be trivial.
1 Like
Eh. The “Windows 95” decorator should probably get a control look and also stay in the tree. There are a lot of people who still use those themes, even on modern GTK/KDE. MacDecorator, probably not so much.
1 Like
You’d be surprised 
5 Likes
That’s not necessarily conflicting, however. It’s possible to have them in the repos and put them in a separate package.
The windows and mac decorators are there for two reasons:
- Testing the decorator API,
- BeOS had them, so we should too, for feature completeness.
In general however I agree we should stop putting everything in the main Haiku tree. We can just add more packages to the releases.
IMO, Haiku should only come with its own (duh) and - as a tip of the hat to its distant ancestor - the old BeOS decorator out of the box. Anything else can be packaged and put into HaikuDepot.
I could imagine a “Get more…” button in the Decorator tab of the Appearance prefs that opens HaikuDepot searching for “Decorator” once there are a few available.
3 Likes
I hate when Windows does that. It looks like “our UI is confusing, so we are adding links to other stuff that is vaguely relevant but we didn’t manage to put together in a single place”
Like, you go to screensaver preferences, and there is a link “did you want to adjust power saving settings?” which opens a different panel. I find this confusing.
2 Likes
I have to admit, this just popped into my head and I haven’t thought much about it. However…
A shortcut to installing more Decorators in the settings for decorators isn’t just “vaguely relevant” IMO.
Sure. But I wouldn’t mind a “Get more…” button in the “Screensavers” tab of the Screensaver prefs either. Feels perfectly relevant there…
1 Like
But we can do this everywhere. “Get More” in translator preferences. “Get More” in keymaps. “Get More” in Appearance to get fonts. “Get More” in application menu to get new applications. “Get More” in Background preferences. “Get More” in media to install MIDI sound fonts. “Get More” in Devices preferences to install drivers. “Get More” in sound preferences to install sounds. “Get More” in Tracker add-ons menu to install add-ons. “Get More” in MediaPlayer to install missing codecs.
See how this pattern is wrong? What we should do is convert HaikuDepot into a really useful GUI, not a bland list of packages. So when you want to install something, it’s obvious you turn to HaikuDepot. And when you run HaikuDepot, it lets you explore its selection in ways that makes it easy to discover things, by having categories, showing recomended apps in an useful way (screenshot preview), etc.
1 Like