search

vially / wayland-explorer

Easily browse and read Wayland protocols documentation
https://wayland.app/protocols/
MIT License
192 stars 20 forks source link

Prettify the source `.JSON`. #65

Closed RokeJulianLockhart closed 1 week ago

RokeJulianLockhart commented 4 months ago

As the undermentioned code demonstrates:

https://github.com/vially/wayland-explorer/blob/067c4045ee1628726e1fd25385abb5b69ffe339d/src/data/protocols/xdg-decoration-unstable-v1.json#L1

...they could be more readable. https://github.com/recurser/string-is/blob/c00f52f94c97efef4cb60babf0d8fed40c41e41c/README.md#string-is produces:

```JSONC { "copyright": { "text": "Copyright © 2018 Simon Ser\n\n Permission is hereby granted, free of charge, to any person obtaining a\n copy of this software and associated documentation files (the \"Software\"),\n to deal in the Software without restriction, including without limitation\n the rights to use, copy, modify, merge, publish, distribute, sublicense,\n and/or sell copies of the Software, and to permit persons to whom the\n Software is furnished to do so, subject to the following conditions:\n\n The above copyright notice and this permission notice (including the next\n paragraph) shall be included in all copies or substantial portions of the\n Software.\n\n THE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\n IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\n FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL\n THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\n LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\n FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER\n DEALINGS IN THE SOFTWARE.", "type": "copyright" }, "interfaces": [ { "description": { "summary": "decoration object for a toplevel surface", "text": "The decoration object allows the compositor to toggle server-side window\n decorations for a toplevel surface. The client can request to switch to\n another mode.\n\n The xdg_toplevel_decoration object must be destroyed before its\n xdg_toplevel.", "type": "description" }, "enums": [ { "bitfield": false, "description": { "summary": "window decoration modes", "text": "These values describe window decoration modes.", "type": "description" }, "entries": [ { "name": "client_side", "summary": "no server-side window decoration", "type": "entry", "value": "1" }, { "name": "server_side", "summary": "server-side window decoration", "type": "entry", "value": "2" } ], "name": "mode", "type": "enum" }, { "bitfield": false, "entries": [ { "name": "already_constructed", "summary": "xdg_toplevel already has a decoration object", "type": "entry", "value": "1" }, { "name": "orphaned", "summary": "xdg_toplevel destroyed before the decoration object", "type": "entry", "value": "2" }, { "name": "unconfigured_buffer", "summary": "xdg_toplevel has a buffer attached before configure", "type": "entry", "value": "0" } ], "name": "error", "type": "enum" } ], "events": [ { "args": [ { "argType": "uint", "enum": "mode", "name": "mode", "summary": "the decoration mode", "type": "arg" } ], "description": { "summary": "notify a decoration mode change", "text": "The configure event configures the effective decoration mode. The\n configured state should not be applied immediately. Clients must send an\n ack_configure in response to this event. See xdg_surface.configure and\n xdg_surface.ack_configure for details.\n\n A configure event can be sent at any time. The specified mode must be\n obeyed by the client.", "type": "description" }, "name": "configure", "type": "event" } ], "name": "zxdg_toplevel_decoration_v1", "requests": [ { "args": [], "description": { "summary": "destroy the decoration object", "text": "Switch back to a mode without any server-side decorations at the next\n commit.", "type": "description" }, "name": "destroy", "requestType": "destructor", "type": "request" }, { "args": [], "description": { "summary": "unset the decoration mode", "text": "Unset the toplevel surface decoration mode. This informs the compositor\n that the client doesn't prefer a particular decoration mode.\n\n This request has the same semantics as set_mode.", "type": "description" }, "name": "unset_mode", "type": "request" }, { "args": [ { "argType": "uint", "enum": "mode", "name": "mode", "summary": "the decoration mode", "type": "arg" } ], "description": { "summary": "set the decoration mode", "text": "Set the toplevel surface decoration mode. This informs the compositor\n that the client prefers the provided decoration mode.\n\n After requesting a decoration mode, the compositor will respond by\n emitting an xdg_surface.configure event. The client should then update\n its content, drawing it without decorations if the received mode is\n server-side decorations. The client must also acknowledge the configure\n when committing the new content (see xdg_surface.ack_configure).\n\n The compositor can decide not to use the client's mode and enforce a\n different mode instead.\n\n Clients whose decoration mode depend on the xdg_toplevel state may send\n a set_mode request in response to an xdg_surface.configure event and wait\n for the next xdg_surface.configure event to prevent unwanted state.\n Such clients are responsible for preventing configure loops and must\n make sure not to send multiple successive set_mode requests with the\n same decoration mode.", "type": "description" }, "name": "set_mode", "type": "request" } ], "type": "interface", "version": "1" }, { "description": { "summary": "window decoration manager", "text": "This interface allows a compositor to announce support for server-side\n decorations.\n\n A window decoration is a set of window controls as deemed appropriate by\n the party managing them, such as user interface components used to move,\n resize and change a window's state.\n\n A client can use this protocol to request being decorated by a supporting\n compositor.\n\n If compositor and client do not negotiate the use of a server-side\n decoration using this protocol, clients continue to self-decorate as they\n see fit.\n\n Warning! The protocol described in this file is experimental and\n backward incompatible changes may be made. Backward compatible changes\n may be added together with the corresponding interface version bump.\n Backward incompatible changes are done by bumping the version number in\n the protocol and interface names and resetting the interface version.\n Once the protocol is to be declared stable, the 'z' prefix and the\n version number in the protocol and interface names are removed and the\n interface version number is reset.", "type": "description" }, "enums": [], "events": [], "name": "zxdg_decoration_manager_v1", "requests": [ { "args": [], "description": { "summary": "destroy the decoration manager object", "text": "Destroy the decoration manager. This doesn't destroy objects created\n with the manager.", "type": "description" }, "name": "destroy", "requestType": "destructor", "type": "request" }, { "args": [ { "argType": "new_id", "interface": "zxdg_toplevel_decoration_v1", "name": "id", "type": "arg" }, { "argType": "object", "interface": "xdg_toplevel", "name": "toplevel", "type": "arg" } ], "description": { "summary": "create a new toplevel decoration object", "text": "Create a new decoration object associated with the given toplevel.\n\n Creating an xdg_toplevel_decoration from an xdg_toplevel which has a\n buffer attached or committed is a client error, and any attempts by a\n client to attach or manipulate a buffer prior to the first\n xdg_toplevel_decoration.configure event must also be treated as\n errors.", "type": "description" }, "name": "get_toplevel_decoration", "type": "request" } ], "type": "interface", "version": "1" } ], "name": "xdg_decoration_unstable_v1", "type": "protocol" } ```
vially commented 4 months ago

Prettifying the JSON files would be relatively straight-forward to implement and it may make sense to implement them.

However, since they are auto-generated from the XML protocol files they are not meant to be edited manually and any potential changes should be submitted upstream instead.

bbb651 commented 1 week ago

This was done in #86, I explained the rational in the PR description:

I need to regenerate all of them, so I added pretty printing for the json while I was at it, it makes them nicer to work with and I think the chance of someone with enough knowledge of how wayland protocols work to use and want to contribute not realizing they are machine generated is really low (I wish there was a way to mark them as generated but I don't think it's worth dealing with jsonc.. that sounds like a good use case for a machine_generated editorconfig property).

RokeJulianLockhart commented 1 week ago

@bbb651, https://github.com/vially/wayland-explorer/blob/9d1c08d9a9002dc0376537342bdd37e0af319aaf/src/data/protocols/xdg-decoration-unstable-v1.json#L1-L181 is brilliant. Thank you!