#196 implement DISABLED conditions: PLUGGED and UNPLUGGED

[mrsobakin]

No description provided.

[mrsobakin]

This branch is based on refactoring in the #198, so apologies for the unrelated changes and dirty diff.

I'll rebase it onto master after the #198 gets merged.

[alex-courtis]

Also... you have access to this repo, so you can push branches directly.

[alex-courtis]

Removed toggles from wiki... many thanks!

https://github.com/alex-courtis/way-displays/wiki/Recipes/_compare/37ae6dff534815459b60568ec05204facff43c7b...92fdef9c5a1e3c167f5c3374e84277f9aad95a08

[alex-courtis]

Sounds like progress. I'll get back to you in my weekend way+displays timeslot.

[alex-courtis]

Looking good: works as expected, doesn't leak, behaviour is intuitive.

[alex-courtis]

Sorry to second guess, but could we simplify DISABLED to use map keys for the monitor?

DISABLED:
  - LG Display 0x05EF:
      IF:
      - UNPLUGGED:
        - XG349C
  - MAG274QRF-QD

[mrsobakin]

We could, but I think that it would be better if DISABLED format was consistent with the rest of the config. NAME_DESC is used in SCALE, MODE, TRANSFORM -- in other words in all places that set some parameters based on the display name. I would say that conditions of disabled fit into that category too.

[alex-courtis]

We could, but I think that it would be better if DISABLED format was consistent with the rest of the config. NAME_DESC is used in SCALE, MODE, TRANSFORM -- in other words in all places that set some parameters based on the display name. I would say that conditions of disabled fit into that category too.

Fair enough.

It also serves to highlight that a condition is used rather than a string.

[mrsobakin]

I think that it's safe to say that this feature is done. If you don't have any further comments, I'll merge this PR into master.

[alex-courtis]

Looks good, let me know if you can't merge it.

What's next for you?

[mrsobakin]

What's next for you?

I've been thinking about #55. At least about some parts of it. wdisplays unfortuantely looks abandoned, and in addition to that, I don't really like developing GUI. That being said, there are still some things that would be nice to have if someone will decide to make a GUI wrapper for way-displays:

• Absolute display positioning (permanent, in config)
• A bit of a refactoring of marshalling
• (maybe) exposing some of the way-displays structs and marshalling functions so that they can be included and reused by others.

I am not a big fan of yaml, especially for IPC, but it's already there and it's better to embrace it than fight it.

[alex-courtis]

I've been thinking about #55. At least about some parts of it. wdisplays unfortuantely looks abandoned, and in addition to that, I don't really like developing GUI.

I also do not like building GUIs.

wdisplays looks dead, it's GTK, and it's not of the greatest quality.

A colleague recently recommend https://github.com/webui-dev/webui which would suit way-displays beautifully - it's c centric and handles calling c from/to js with ~0 effort. It does, however, still need someone to write the actual front end functionality.

I'll update the issue and call for volunteers.

That being said, there are still some things that would be nice to have if someone would decide to make a GUI wrapper for way-displays:

• Absolute display positioning (permanent, in config)

That'd be great; I think some users do want that.
Care needed: sway does behave strangely when there are gaps between displays, with mouse getting stuck and some window rendering oddities.

• A bit of a refactoring of marshalling
• (maybe) exposing some of the way-displays structs and marshalling functions so that they can be included and reused by others.

Yes please, it's become very unwieldy.

A move away from yaml-cpp would be good; it's buggy, some API is broken and it has broken compatibility (ABI and API) several times over the years.

I am not a big fan of yaml, especially for IPC, but it's already there and it's better to embrace it than fight it.

yaml for config is something I've carried over several projects, starting with one that was a plugin to an existing framework that used yaml. I've warmed to it over the years - github actions and bitbucket pipelines work very well.

Agreed on IPC; I lazily rushed that through when someone volunteered for a GUI but never came through. JSON isn't really any better than yaml.
Protobuf or even just raw binary objects (like wayland) would do the job far better.

[alex-courtis]

Let's both test this for a week then release 1.14.0

[alex-courtis]

https://github.com/tlsa/libcyaml looks promising - c centric and very memory safe (configurable allocator).

It was released after I first started using yaml-cpp

[mrsobakin]

https://github.com/tlsa/libcyaml looks promising - c centric and very memory safe (configurable allocator).

It was released after I first started using yaml-cpp

There's also libyaml, which is currently maintained by the YAML community. It's used by multiple projects, so it should be already installed on the majority of systems.

I personally think that yaml-cpp is acceptable. Serialization in languages without reflection is prone to require a lot of boilerplate code. C++ and C both don't have it, and I'm not sure which would look clearer.

[alex-courtis]

Released https://github.com/alex-courtis/way-displays/releases/tag/1.14.0

Love your work!