Hello, unfortunately for some reason I'm not receiving mails from the gnustep lists, so i have to look to the lists by myself going to the archives, that's why i reply so late.
I want spend some words on this concept. In early novemeber 2021 i had the same idea, but in a more complex way because in my situation, the window manager, uroswm, would communicate with the Puck dockbar and viceversa. I was using threads (NSThread) to make the uroswm acts as a server too, and threads to make the dockbar sending and receiving responses from the server. The concept was nice as idea and elegant, but unfortunately i had to abandon it. The first reason: They were working quite well with GNUstep apps. In few words: the code was totally a mess for non gnustep apps. Full of syncronization code here and there. While with GNUstep apps i can send views and menus, directly using GNUstep classes and features (using DO), making the same for non-gs apps was inevitably involving X11 (and really tricky). My goal is making a window manager and a dockbar (and more in generale a DE) that privileges GS-apps, but that integrates in the best way, non-gs apps too. So I had two different behaviors for 2 differents app classes but that relies on the same "framework", X11, making the code harder to mantain and readable for other devs and i don't want this. The second reason: In december or late november, wayland devs added, with the last release, official support for FreeBSD and seems that nvidia finally is going to full work with wayland. I was waiting the annouce for FreeBSD, because I chose to to don't add so many feature to XCBKit (both uroswm and Puck relies on it), in the case wayland will be really the mainstream open source Window System. Probably I will add COMPOSITE extension and nothing more to it. The point is this one: when Puck will reach a fullset of features that I need to use it productively, i will start another project: WaylandKit. This time WaylandKit will not be a kit to implement window managers, but it will start really generic giving the possibility to "interact" with wayland in objc. I will write a wayland compositor using WaylandKit. Also, Puck is not a proof-of-concept dockbar, it is a real dockbar in early development. I just took a pause from development because i had too many ideas in a short period making me writing messy stuffs. Actually Puck can dock iconized windows in an iconized window container, as the same as OSX does (on the right of the dock). This code is still not pushed but working, because i have to polish it a bit, probably i will do it in next week, the pause is going to finish, also because i almost reached the goal in the "pause project": making a 2 server toy system on top of GNUMach with one that acts as nameserver registering other servers, and a little client that ask for server ports via the nameserver (this is a little bit offtopic i know). It was really funny and distracting, helping me to put order in the mind for the Puck development. Cheers, Alex. -------------------------------------------------------------------------------------------------------------------------------------------------------- A neat dock! It's good that you don't use libxcb or other xorg libraries. I've seen other proof-of-concept docks that depend on libxcb e.g. https://github.com/AlessandroSangiuliano/Puck and considering the long-term move to wayland-based environment this is a better approach. On Tue, Dec 7 2021 at 01:20:36 PM +0100, Riccardo Canalicchio <riccardo.canalicc...@gmail.com> wrote: thanks for the feedback, it is really appreciated, the idea of DO came from looking at the osx api for the NSStatusBar [1] ideally one could have something like: [[Dock systemDock] registerDockTile: dockTileView]; [dockTileView setTitle:@"My app name"]; [dockTileView setMenu:menu]; ... [dockTileView setBadgeLabel:@"4"]; I did evaluate different approaches less invasive from the "client" point of view but they would require different implementations based on the backend in use and would lead to different results. This is because they would need to reparent the mini windows to the dock. On Xorg this could be achieved using Xembed [2] (kde used to have something like this) while on wayland with the XDG foreign protocol (unstable atm) [3]. In the end, I opted for DO mainly because it could be implemented entirely in gnustep, it would be consistent across backends and would provide all the features I would expect from a dock as well the possibility to render the tiles in a cohesive way. To make the dock registration optional for apps and support non-gnustep applications the dock could have a mechanism to automatically generate dock tiles listening to the running processes and then allow through the api to customise the appearance and the menu. Contributions also in the form of suggestions are more than welcome :D best regards, Riccardo [1] https://github.com/tjarratt/NSStatusItemExample/blob/master/NSStatusItemExample/AppDelegate.m [2] https://specifications.freedesktop.org/xembed-spec/xembed-spec-latest.html [3] https://wayland.app/protocols/xdg-foreign-unstable-v2
