Anyone else working on this to support also Wayland (labwc/waybox)?

[redtide]

I'm currently working on a code derived from this, removing openbox libraries dependencies to make it working as generic configurator for Openbox based systems. So this is not an issue but just a question to see if there are other people interested on a similar goal and possibly to share some work.

[stefonarch]

That's good news, especially now that the next labwc release includes quite good support (with window rules) for desktop and panel. I doubt that this here has a great visibility though.

[redtide]

I doubt that this here has a great visibility though

yes, was just a question to know if anyone of the devs was still following this project and eventually had in mind to port it to work with Wayland stuff. Maybe was better to open a discussion on LXQt repo? I've mentioned it here yesterday.

[johanmalm]

For info:

• https://github.com/labwc/labwc-tweaks/pull/30

[redtide]

Maybe at this point would be better to discuss to see if to collaborate on the same application, though my idea was to make it xml schema based and work also for other openbox based WMs (so X11 included, not just Wayland), but maybe it's too late to support also X11, IDK.

[johanmalm]

Maybe at this point would be better to discuss to see if to collaborate on the same application

Yes we ought to :smile:

Is a best next step to try to describe intended scope to see if we can find an acceptable middle-ground to avoid duplicated effort?

Some considerations off the top of my head:

1. Should it support openbox AND labwc? If so, how do we handle differences (for example the current labwc-tweaks Language & Region tab)? I'm quite easy on this, but I think suspect that supporting both in the same application will create a lot of extra work.

2. Do we want to support all settings, or just a subset? As a starting point, my thoughts are that a slimmed down GUI is probably a lot more helpful to most users rather than a big/complex one that supports every weird/wonderful setting. But again - open to ideas.

3. What underlying stack do we use? obconf(-qt) relies on a bunch of openbox code (both theme rendering + xml parsing IIRC). My sense is that it is simpler to de-couple that dependency and just re-write a few functions from scratch.

4. I have no experience with Qt and XML-schemas, so not sure how much comes for free there. The thing to consider is labwc's relaxed element/attribute interchangeable parsing though.

In terms of "one-size-fits-all", it's worth considering that labwc is quite different from openbox when you look at the detail. Consider a super-quick analysis of the the key config file heading below. This is largely intentional to give labwc the freedom to grow as it needs to without unnecessary limits (we have enough of those anyway :smile:). We could have insisted on being an `openbox' port/clone, but we haven't.

<core> (labwc only)
<windowSwitcher> (labwc only)
<resistance>
<focus>
<placement>
<snapping> (labwc only)
<regions> (labwc only)
<theme>
<desktops>
<resize>
<keyboard>
<mouse>
<touch> (labwc only)
<tablet> (labwc only)
<libinput> (labwc only)
<margins>
<menu> (not yet used)
<windowRules> (different - openbox has an <application> section but the syntax is different)

References:

• https://github.com/labwc/labwc-scope/blob/main/extra.md
• https://github.com/labwc/labwc-scope/blob/main/deviations.md

[redtide]

I'll join IRC for details on this, meanwhile:

1. Should it support openbox AND labwc? If so, how do we handle differences (for example the current labwc-tweaks Language & Region tab)? I'm quite easy on this, but I think suspect that supporting both in the same application will create a lot of extra work.

That's what I wanted as requirement for some reasons.

2. Do we want to support all settings, or just a subset? As a starting point, my thoughts are that a slimmed down GUI is probably a lot more helpful to most users rather than a big/complex one that supports every weird/wonderful setting. But again - open to ideas.

All settings needed for the 2 backends (Openbox and Labwc at the moment), of course different backends, can be different settings, need to think about this. The GUI is a view, you can make it as Advanced and Quick views to filter what is used often and what not.

3. What underlying stack do we use? obconf(-qt) relies on a bunch of openbox code (both theme rendering + xml parsing IIRC). My sense is that it is simpler to de-couple that dependency and just re-write a few functions from scratch.

I started too from scratch using pugixml and Qt, but this might be annoying if you need to use your xml library in labwc, so I could adapt in some way.

4. I have no experience with Qt and XML-schemas, so not sure how much comes for free there. The thing to consider is labwc's relaxed element/attribute interchangeable parsing though.

It was an idea to use xml schema as experiment if was possible to automate the creation of UI at runtime, following precise rules, so maybe I should reconsider it, unless as we had a talk about this, we can follow just one way with the file, making personalization not possible since it would be overwritten anyway.

In terms of "one-size-fits-all", it's worth considering that labwc is quite different from openbox when you look at the detail. Consider a super-quick analysis of the the key config file heading below. This is largely intentional to give labwc the freedom to grow as it needs to without unnecessary limits (we have enough of those anyway 😄). We could have insisted on being an `openbox' port/clone, but we haven't.

It's not really a one size fits all, it's more about having a single structure that adapts for each backend. Though I see there are some complications that might require too many efforts.

[stefonarch]

I'm not sure if supporting an in-fact dead WM is worth the effort, another things are other apps that lacks a xml config editor, but I'm not aware of one.