Roadmap

[wizbright]

Features

• obMenu System
  • Application Listings
  • Places
  • Menu Editor
  • obConfiguration
    • obKeyConfig
    • obThemes
    • taskbar Support
    • Handling GTK and QT styling
      and applications
  • autostart

Graphical

• ob Window Decorations
  • icon, minimal
• Notifications
• Logout/Shutdown screen overlay
• Workspaces
  • Naming
  • Moving windows between
  • Workspace focus
• Layers (wlroots surface layers should help)

[matthewhartman]

this is really awesome!

Forgive my ignorance (it might be in the list above) - any chances of having a config file similar to rc.xml where you can configure window snapping, shortcuts, etc?

Looking forward to seeing future updates for this project :)

[wizbright]

It'll happen eventually. I still have quite a bit of work to do. I plan to hopefully make it easy to swap over similar to i3 >> sway

[matthewhartman]

Sounds awesome! Thank you for your hard work! 👍

[Zjemm]

nice, gonna keep an eye on this

[keithbowes]

this is really awesome!

Forgive my ignorance (it might be in the list above) - any chances of having a config file similar to rc.xml where you can configure window snapping, shortcuts, etc?

It would be awesome if it had shortcuts now. As far as I can tell, it currently doesn't do much. It won't even compile with the latest version of wlroots, which I have for Sway 1.1.1, but with older version of wlroots, I suppose you can open programs by using the WAYLAND_DISPLAY environment variable, but as far as I can tell, you can't use Waybox as a standalone compositor.

It should be fairly easy to parse rc.xml with libxml2 or some other DOM library. Though, Openbox's system for defining keys is kind of weird and I think it should be deprecated. Again, you can use libxml2 to rewrite rc.xml in the new format:
OpenBox's format:
<keybind key="A-F2">
My proposed format:
<keybind key="F2" modifier="Alt" shift="0">

Other changes that should be made:

1. Allow defining the keyboard layout (possible to define through environment variables, but settings in rc.xml would make configuring through a GUI configuration program easier). I'd suggest something like:
   <keyboard>
   <keymap>
   <layout>us</layout>
   <model>pc105</model>
   <options>lv3:ralt_switch_multikey</options>
   <rules>evdev</rules>
   <variant>dvorak</variant>
   </keymap>
   ...
   </keyboard>
   [Again, libxml2 could automatically add the <keymap> section, perhaps based on the environment variables, if it's not already there.]
2. Allow setting the background. swaybg could probably be used. The Openbox config already has configurations for different monitors, so that could probably be changed to wlroots outputs and a <background> or something added.
3. Ideas from Sway I'd really like to see:

• An equivalent of for_window (that is, customizing a window's attributes by AppID, title, etc.).
• The ability to move and resize windows without a mouse.
• Something like swaybar. I use tint2 in Openbox, but that's not possible in Wayland. Perhaps Waybar could work. I have my own shell script in Sway, generating JSON in a loop, but something tells me that's not the most efficient.

[wizbright]

Currently, it does not do much as I am working and haven't really had the drive to work on this. I am open to discussion and having a more defined keymap does make sense.

1. I will have to look into this more. I would need to familiarize myself with the way they accomplish things before I feel comfortable deciding.
2. Backgrounds by default could probably use swaybg as a default way to set the background but I would still want to allow the user to decide what to use if there are alternatives.

---

As for the ideas from sway:

1. Customization of window's attributes was handled by openbox, I would want to approach it similarly.
2. Possibly an idea but that functionality to me seems to fit more with i3 and sway than openbox.
3. waybar is something I have looked at and would not mind trying to provide that as a base, but again I would want users to be able to use their own if needed.

[jvalrog]

You could also get rid of the XML part and adopt a simple configuration file.

[keithbowes]

You could also get rid of the XML part and adopt a simple configuration file.

I vote against. XML is really easy to parse through libxml2. The configuration of i3/sway is really a mess and anyone who wanted to parse through it (like for a GUI configuration manager) would have to write their own parser, but someone could easily write their own tools for an XML format. I've been using Sway but I really want to use something that has features that Sway lacks (title bars, ability to close a window without killing the whole application, minimizing applications, stacking windows, smart window placement, application menus, etc), so I've been working on Waybox, as I seriously doubt Sway would be willing to adopt these features (Drew seems to want Sway to remain a drop-in i3 replacement, not breaking from the tiling paradigm the least bit).

Of course, over the past couple of days, I've been working on porting obmenu instead of directly working on this. Maybe I'll also do obconf down the road, but that seems harder; obconf segfaults in Wayland.

In fact, one thing I've been thinking about is theming. I'd prefer to use an XML-based format for that too instead of the ad-hoc format used by Openbox, but that would mean existing Openbox themes would be unusable.

[keithbowes]

1. Customization of window's attributes was handled by openbox, I would want to approach it similarly.

Yeah, I was looking through rc.xml the other day and noticed the <applications> element. I'd never seen that before; it seems like an adequate base. An eventual GUI configuration tool should also allow configuring per-application settings, kind of like winecfg does for WINE.

[Beethoven-n]

i'm coming from fluxbox's side of things, and the only compositor that tried to reimplement that style of config is dead.
can this count as a vote in favor?
icedman/tinybox#2

[keithbowes]

i'm coming from fluxbox's side of things, and the only compositor that tried to reimplement that style of config is dead. can this count as a vote in favor? icedman/tinybox#2

I used Fluxbox before going to OpenBox. The primary reason for the switch was that OpenBox used the XDG directory layout. XML is easy to work with, so I vote to keep it, but I don't want to slavishly imitate OpenBox. I'm probably about 90% the way of what I actually want: there are still a few protocols I want to implement (output-management, foreign-toplevel-management, and idle-inhibitor). I'm not interested in a few of the items in this list (namely server-side decorations (client-side decorations are fine with me) and a taskbar (I use Waybar, like I used tint2 with OpenBox); no server-side decorations also means no theming) but @wizbright might still be set on implementing them. I should probably implement workspaces and support for multiple monitors, two features that I've never used but seem ubiquitous. I do want to set up a menu system, but I still think it will be far easier to use a GTK menu with gtk-shell than reinvent the wheel with Cairo. I also want to have fullscreen support, but I don't know how to go about it; according to the wayland-protocols developers, the fullscreen-shell protocol is obsolete.

[Narrat]

I should probably implement workspaces and (...)

Oh, yes, please :D For me the main feature for a suitable window manager / compositor