Rather than having every dev, for every app, write basically the same code to implement closing, maximizing, and minimizing, please provide a default title bar. Especially with OS windowing enabled, in the manifest, one would think that the OS-provided title bar would show.
impact for my app: [low, mid, high, show-stopper].
This is relatively low impact, since it can be worked around with some code, but it’d be better for all new devs to have a sane default so they can focus on building their app’s business logic instead of implementing windowing functions.
What is your current pain point?
What do you have in mind to solve it?
Please allow devs to opt into a default OS title bar which behaves as the user would expect.
note for stuff: after FR is accepted, add a link to the internal ticket.
@jeaye if you enable the use_os_windowing manifest flag, you get the default title bar, that includes closing and minimizing. So the only missing button is the maximize()?.
In addition, you can use our sample app as a base for the title bar.
Is there any thing else that i’m missing here?
will get the minimize and close buttons. and also the transparency slider. So the only missing button is the maximize button.
Anyway, most of the apps prefers to implement there own look and feel
@eransharv, please refer to this discussion I had with Tom: Slack
In short, we cannot reasonably play videos (which we do a lot) without 100% CPU usage unless we enable native_window. However, enabling native_window means we don’t get the title bar, even if use_os_windowing is enabled. So we either get the title bar and unusably slow video decoding or we get hardware-accelerated video decoding and no title bar. It would be nice for people to have both!
Hi. I checked it internally and find that most of our partners prefer to have the ability for a custom bar.
In your case, you can use the sample app title bar, as it’s built according to our best practices.