Your “Get more” scenario doesn’t fill my heart with terror, to be honest. 
If it’s in an area where it is actually useful. For example, it’s not for fonts, backgrounds, sounds and midi soundfonts, as those usually don’t come as HPKG from HaikuDepot, but are downloaded somewhere or created by the user (in case of backgrounds and sounds).
Keymaps, drivers and codecs I expect to come with the system and wouldn’t have the user care about those.
It can only make sense for stuff that’s in HaikuDepot, which limits it currently pretty much to screensavers and maybe translators (though I’d argue Haiku should bundle thouse anyway, as long as they are not too esoteric).
Somebody has got to make stack and tile work with those decorators that’s my main concern. I am not opposed to a Get more option that takes you to the appropriate place in Haiku Depot for screen savers or decorators.
We have more fonts in HaikuDepot than screensavers and translators combined.
Screen savers: 10 (and an X11 library extension that I don’t know why we package)
Translators: 6
Fonts: 47
Expecting all translators to be part of the core OS is unreasonable. The haiku team cannot be put in charge for support for every format out there. What’s the point of making it a plugin system where users can add more formats otherwise? For keymaps, it is perfectly fine for a small community of users to create their own map (this is how Bépo was initially designed, and it was not included in Haiku until it got enough traction). What if another such layout emerges? Is it all or nothing? Either we include it in the OS, or we offer no way to package it?
For drivers, it is also a similar situation. It would be great if users wrote drivers for their own hardware and shared them. Why would it be restricted only to the Haiku developers? Why would everyone need to send their drivers to us for adoption?
In other words, I don’t see why you are making applications a special case, the only place where other people would be allowed to contribute outside the main git repo of Haiku. I don’t think this is the right way to go. We should encourage people to do nice things in all areas of the system, experiment with it, write drivers, apps, decorators, packages, screensavers, etc. And share them. And maybe we will adopt some of it if we think it’s relevant, to include in our releases.
I have plan for rather weird codecs one wouldn’t need in normal cases. For example to open tape files for games for my Amstrad CPC (or other 8bit computer) as soundfiles. Should this be part of the default install? definitely not. Is it useful to at least some of our users? Yes, either those using an emulator that can load tape data this way, or to people who just want to play the sound into a tape adapter to load on the real machine.
Likewise, I could make a translator to open files saved with Oxford PAO on the same Amstrad CPC. I could write a filesystem add-on to access floppy disks saved on that machine. Should that be part of Haiku? Again, definitely not. Should it be up to other Haiku core devs to maintain this code? No, certainly not. So, these will be 3rd party packages, of course.
Which leads me to “get more” in DriveSetup to install filesystem add-ons.
Really, let’s keep installation contained in a single place, and that should be HaikuDepot. Otherwise, eventually every application out there will eventually include a “Get More” button. Being modular and allowing to plug applications and add-ons together is at the heart of how Haiku applications are used, so the availability of extensions like this will be everywhere. And the user should know where to go to find add-ons of all kinds, without needing a hack like this to bring him to a specifically crafted search query in HaikuDepot.
1 Like
Sure, but that is still a few thousands short of what’s available online, and I dare say that’ll stay that way. As well it should!
That’s not at all what I was saying. The opposite actually, as I suggested to not include those Decorators, but have their HPKG in HaikuDepot.
Again, I never suggested to have all drivers etc. included in the Haiku tree. Just to add the more popular ones as bundled package with the installation.
Exactly. That would fall under what I termed “esoteric” above.
It would just be a shortcut to the HaikuDepot app, and I suspect people will see and notice that the HaikuDepot is the mother of all software in Haiku.
Anyway, the whole “Get more” was only a one sentence afterthought, and I neither feel strongly about suggesing to go that route, nor continue this sidetrack much further, if you don’t mind.
1 Like
I did not plan. Maybe in the future I will publish on github.
Small update HAKILO Decorator Pack v.1.0.2
- New decorator HakiGameMDecor like Mario colors
- New decorator HakiGameLDecor like Luidgy colors
Download
Hakilo DecorsPack 1.0.3 32bit HPKG
Hakilo DecorsPack 1.0.3 64bit HPKG
4 Likes
I like the rounded buttons! It’s part of the decorator?
1 Like
No. It’s my HakiControlLook (early version ). You need rebuild Haiku, to use it
1 Like
Please do, so we can write a haikuport recipe for them, and use them in ThemeManager 
3 Likes
Btw, I have an archive of an attempt at skinning controls in BeOS here. don’t think there’s much to reuse, maybe some QNX skin stuff, although it did gradients by hand. I’ll try to publish it on github.
2 Likes
Why do you need separate decorators just to change the colors? Don’t they get colors from Appearance preferences?
I need decors with specific colors. I did not plan to change colors in them.
Nice! Not only to have it, but to learn about decorators by example.
You must add license there.
1 Like
It doesn’t matter to me. Without a license
It is a matter to others. Without a license Haiku can’t use the code.
1 Like
Still, it’s always better to leave the possibility. I don’t recall how the API works, but if it’s well done it should leave the possibility to have default colors and yet change them. Else it can probably be fixed 
Yes please, put a FLOSS license to it, even if it’s the WTFPL, it makes things clear what people can do with it.