compat: add window_properties object to json output of views

[Snaipe]

Some existing tools that rely on i3's json output, like the i3ipc
python module and scripts using it, break when they can't find the
window_properties object in a view.

To achieve a better drop-in replacement compatibility with i3 and
existing tools for it, we add the window_properties object to
the output of get_tree, along with the "class", "instance", and "title"
sub-fields. These three values are set to the view's class, app_id,
and title respectively.

In addition, if the view does not have a class, window_properties.class
is set to the app_id, to avoid breaking tools that expect all windows
to have a class in the X world.

Signed-off-by: Franklin "Snaipe" Mathieu me@snai.pe

[ianyfan]

This fallback isn't performed for the same property above. Should it?

[Snaipe]

Yeah, I initially put that at the top, but wasn't sure if that was completely the right fix. I guess we can have this fallback in place for both and see if anything breaks down the line.

[RyanDwyer]

-1 to this. Loading the app id into the class or instance fields makes it confusing to end users. I value transparency - that is: telling the user what the properties actually are - over trying to allow for a zero configuration port between i3 and sway. I would add an app_id property, set it accordingly, and let the class and instance be null. This is the approach we've taken with criteria too.

[Snaipe]

I would have agreed with that point if sway didn't try to pretend it was i3: by providing I3SOCK, you're pretty much promising that existing programs written for i3 are still going to work under sway, which is not really true as it is.

Would it be reasonable to stop populating I3SOCK altogether, or alternatively set it to a socket serving an i3-matching fallback protocol? I'm fine with either, but keeping the status-quo is confusing and against the transparency you advocate.

[Snaipe]

Wow, sorry for the spam, looks like GitHub is choking on requests right now.

[RyanDwyer]

I don't have a problem with setting I3SOCK because there's no bad consequences for doing it. But putting the app id into the class and instance is a decision that we could be forced to live with for a while, can confuse and frustrate users, and will become a legacy (especially when users no longer run Xwayland).

[progandy]

As a compromise, maybe set the class to wayland if it is a native wayland window?

[Snaipe]

Alright. I somewhat find it just as frustrating to see every single ipc script that check the instance or the class of a window completely break, but I can see why you wouldn't want that in sway. I just hoped that sway would own being its own thing for the sake of consistency.

I'll just write a standalone ipc proxy providing an I3SOCK socket to convert from the sway-flavored json to the i3-flavored one in the meantime.

tl;dr: Dropping this PR; window_properties are very much more so a compatibility thing with i3 rather than something critical.