Move headers needed for decorator add-on to headers/private

[X512]

This is hrev54302.

It will simplify creation of third-party decorator add-ons.

[X512]

Related discussion: ​https://discuss.haiku-os.org/t/decorators-and-controllook/9611.

[CodeforEvolution]

I feel that it would be better to create a “higher level” decorator api that doesn’t require private apis in the first place. I mean, I even had to put Freetype 2 headers into my “SDK”. Any user-made decorator should be greatly separated from this sort of low level functionality. (I’m actually quite concerned about how many “out of tree” applications are using private apis. I’m concerned that this will become a huge api compatibility problem in the future.)

[waddlesplash]

Most of the out-of-tree applications using private APIs are actually using things from the "shared" kit, like BToolBar or BColumnListView, which come from a static library; so whenever we change the ABI here, the applications will not need to be recompiled because of that. So at least this will not be a compatibility problem.

Kernel add-ons are much more of a potential problem, but there are very few of these out-of-tree, so it isn't a huge issue for now.

[pulkomandy]

It's not just about moving the headers in any case, but making sure the API is actually stable before we allow 3rd party uses. Otherwise their work is just wasted whenever we change the API.

Which is why the plan is to first have well-working decorators in tree (that's the point of BeControlLook and the MacDecorator/WinDecorator/BeDecorator). When we're confident that the API is good enough for these, we will consider making it public.

In the case of decorators we may be quite close already, but for control look the API is still under development and seeing many changes as we progress with the BControlLook.

[X512]

Replying to pulkomandy:

It's not just about moving the headers in any case, but making sure the API is actually stable before we allow 3rd party uses. Otherwise their work is just wasted whenever we change the API.

Unstable API is not a big problem because source code can be easily adjusted and rebuilt. Stable decorator API will be difficult because it depends on drawing engine that will likely changed many times to support vector graphics rendering in WebPositive. Also running add-ons in app_server is dangerous, some app_addon_server should be introduced.

[CodeforEvolution]

I would have to agree with stippi here. I don’t believe it’s a good idea to assume that a developer would be willing to continuously update their code to target a volatile api like app_server’s. Especially with a weaker project like Haiku where we’re low on developers, it is CRITICAL that we try to give developers a stable api to make them feel comfortable to continue developing on our platform.

In addition, I’d once again like to argue that I don’t feel that out-of-tree source code should be using headers from headers/private, as once again, those apis are “volatile”.

Finally, I do agree with X512 that some app_addon_server should be introduced eventually to protect the app_server from rogue add-ons.

[waddlesplash]

Using things from headers/private/shared is fine, like I said, as these are linked against a static library so it's not much different than copying those files into your application.

I also am not so sure about app_addon_server, it sounds like a significant amount of overhead. But if a way could be found to make Decorators use the BView drawing APIs that way, maybe it is a good idea.

[pulkomandy]

In addition, I’d once again like to argue that I don’t feel that out-of-tree source code should be using headers from headers/private, as once again, those apis are “volatile”.

As waddlesplash mentionned, there is a precise rule as to what gets into private/ and published to the image precisely to avoid problems.

The idea is that we have a libshared.a which is statically linked, and everything that goes in there is also in the BPrivate namespace. As a result, compiled apps embed this code and will continue to run fine in future Haiku versions. We use this as a kind of staging area for work in progress APIs in a safe way, and when we think the API design is done we can move these things out of libshared to the appropriate kits.

This of course doesn't work for the decorators.

As for moving the add-ons to a separate server, would that work? You'd have to set up an IPC to call everytime you want to draw something, right? What is the performance and complexity cost of this? What happens if the app_addon_server crashes? What if a malicious add-on messes up with the IPC in some way? What if it draws a fake password prompt and manages to intercept keystrokes in some way?

I'm not sure we can easily solve this, except by not allowing decorator and control look add-ons at all. In any case it needs more thinking and careful design, and certainly a lot more major changes if we want to have some kind of security here.

[X512]

app_addon_server can use regular app_server link protocol and fake BWindow and BView to draw window border. BWindow and BView will have same size as screen. Input handling can be also done by BView.

When app_addon_server crashes, app_server should switch to default decorator and launch_daemon should attempt to restart app_addon_server.

[CodeforEvolution]

The idea is that we have a libshared.a which is statically linked, and everything that goes in there is also in the BPrivate namespace. As a result, compiled apps embed this code and will continue to run fine in future Haiku versions. We use this as a kind of staging area for work in progress APIs in a safe way, and when we think the API design is done we can move these things out of libshared to the appropriate kits.

I see now, I was just concerned about how we'd handle compatibility moving forward. I don't want to sound harsh, but I'm just a programmer who is overly concerned. :)