Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Major refactor #59

Merged
merged 40 commits into from
Jan 11, 2025
Merged

Major refactor #59

merged 40 commits into from
Jan 11, 2025

Conversation

wmww
Copy link
Owner

@wmww wmww commented Jan 11, 2025

There's a lot in here, but the gist of it is I'm moving towards supporting more toolkits than just GTK and more protocols than just Layer Shell in the future. This refactor modernizes the code style, moves a lot of things around and adjusts abstractions boundaries to work better for this goal. The gtk4-layer-shell API is unchanged, the tests still pass and (hopefully) users should not be affected, though with this much code churn there's a chance of issues.

wmww added 30 commits January 4, 2025 04:00
…s info is already provided in the interface arg
@wmww wmww merged commit c8b470f into main Jan 11, 2025
1 check passed
@Beryesa
Copy link

Beryesa commented Jan 11, 2025

Do you plan to split the repos or transform this one into an overall layer shell lib collection? 🤔

@wmww
Copy link
Owner Author

wmww commented Jan 12, 2025

I'm not sure. Single repo seems like a good idea. Probably wont change the name even if the scope grows, so as not to break links. Currently I'm thinking:

  • Add ext-session-lock support, and expose that in the GTK4 Layer Shell API
  • Keep everything that isn't GTK-specific in a subdirectory that can be used by non-GTK programs. I probably won't guarantee a perfectly stable API for this, advise distro packaging, or "officially" support it, but it will be easy enough for projects to copy or submodule it into their projects at a specific commit
  • Maybe build a .so that can be LD_PRELOADed into any program to make it use Layer Shell? (this might ship with gtk4-layer-shell or be its own package)
  • Possibly add "supported" libraries for other toolkits with their own packaging/versioning (Godot is of particular interest to me)

I'm open to feedback on all of this!

@Beryesa
Copy link

Beryesa commented Jan 12, 2025

Probably wont change the name even if the scope grows, so as not to break links
GitHub won't break the links, redirects should work

If you would like to make some kind of common library, e.g. layer-shell-collection, it'd probably be better for someone searching for the godot lib 😅
But if you're just experimenting for now, turning back and forth would be more messy I guess

Maybe build a .so that can be LD_PRELOADed into any program to make it use Layer Shell?

Like reimplementing their wayland toplevel supports to become layer-shell? (That was how the gtk3 version worked afaik(?))

I'm open to feedback on all of this!

An issue or discussion would be nice to hear from people :P

Perhaps other projects would be more open-minded on upstreaming though? There might not be a need for an external lib for long.

Thanks for working on this project :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants