Proposal: titlebar widgeting specification

[notebook]

Without having much say, ...

> 1. Add widgets to the title bar (such as labels, text inputs, buttons, checkboxes, combo boxes, etc...) to combine the benefits of CSD and window managers

I extremely like this idea!
I would hope that this brings back together window manager windows and the current CSD implementations.


>  2. Get information about the window manager's appearance to implement CSD without off-putting the user

I'm too rookie to judge about the importance of (2)

Regards,
Chris | DarkTrick


On 2022/07/25 5:28, samuel ammonius wrote:
> I don't have any rock-solid plan for this specification, I'm just throwing it out there for discussion. I'm using the term "window manager" synonymously with "wayland compositor" throughout this email. The idea is that window managers could provide an API for applications to do either of the following:
> 
>  1. Add widgets to the title bar (such as labels, text inputs, buttons, checkboxes, combo boxes, etc...) to combine the benefits of CSD and window managers
>  2. Get information about the window manager's appearance to implement CSD without off-putting the user
> 
> 
> An API like this could then lead the way for real widgeting toolkits to integrate it into their syntax without much contrast. For example, GTK could have the headerbar use this API once GNOME's window manager supports this specification, or Qt could create a QTitleBar widget with a similar syntax to
> QToolBar (including functions like addWidget, addSeparator, and so on). This will allow both developers and users to get the best out of what both CSV and window managers have to offer, and to be relieved of having to pick one or even not getting to choose.
> 
> The challenge with creating something like this is that it will have to be very well designed if we want to avoid either driving developers crazy or destroying
> performance through something like a CSS parser. A design like this is possible, but still a challenge. There's a lot of possible ways that the API could look, so I'll
> give a brief template to get started:
> 
> ____  (This code is going to look horrible on any email clients that don't support HTML)  ___________________
> 
> #include <xdg/tbwidgets.h>#include <time.h>intmain(intargc,char*argv[]){TitleBar *bar =get_titlebar(/* pointer to X11 Window / Wayland shell surface */);TbWidget *checkbox =titlebar_add_widget(bar,titlebar_button,"click me!");
> 
>      TbWidget*btn =titlebar_add_widget(bar,titlebar_button,"click me!");TbWidget *label =titlebar_add_widget(bar,titlebar_label,"<--- click it!!!")titlebar_widget_set_text(label,"<--- nevermind, don\'t click it!!!");titlebar_widget_set_tooltip(label,"clicking it will trigger the end of the world");titlebar_remove_widget(bar,btn);update_titlebar(bar);sleep(99); /* showtime! */}
> 
> ____________________________________________________________________________________________
> 
> This template shows some basic functions that probably wouldn't change much in the future. The rest of the implementation could be done in many different ways,
> each with their own pros and cons. Here's a few of the questions that would need to be answered:
> 
>   * *Communication -* How will the API communicate to window managers? One option is DBus. Another option could be a standard location for window managers to place libraries (eg. /usr/lib/tbwidgets/[openbox].so) which implement the specification, but this would require loading those libraries during runtime rather than compile time, and I'm not sure if that's even possible.
>   * *Layout API -* The possibilities for how apps may want to organize the titlebar in different situations is infinite. An app may want to set a maximum and minimum size for widgets, may want to use relative or absolute sizing/positioning, may want to hide/shrink certain widgets when the titlebar is too small, and so on, so a CSS property-like solution would be a bad approach. I think the only way to give users the ability to place widgets however they want is to have the user create a function that takes an unsigned int parameter for the titlebar's new length, and have a function like "titlebar_set_resize_callback(TitleBar *bar, void(*callback)(int));" that the user can pass their function to. This callback function could then be called by the internal API right before the widgets are rendered whenever the window is resized horizontally.
>   * *Info detail* - This question applies to the second part of the API as mentioned in the introduction. When an app wants to get data about a window manager so that it can implement CSD (or maybe even style the app based on the appearance of the window manager), what kind of info should be available and how should that info be organized? It could get very complicated to offer all of this information considering things like gradients, animations, borders, shadows, fonts, etc. I don't have any good solutions to this so far.
>       o On the topic of how this info will be designed, there would need to be a way for apps to be alerted when a window manager changes its appearance (aka theme or style). Obviously it would be a good idea to let users assign a callback to this event, but we can also give the user /pointers /to titlebar info rather than the actual info. That way when a user sets (for example) the background color of a CSD button to the background color of the window manager's buttons, the CSD button background color will sync with the window manager button's background color even when it is changed and a callback won't be needed.
> 
> 
> Does anyone think this specification would be a good idea?
>