emallson / gram Goto Github PK

Right now it is possible to bind keys to switch to static layouts. For example:

(define-key! default-keymap (kbd "M-1") (cut switch-to-workspace "1"))

However, the names have to be hard-coded. It would be ideal to prompt for these.

We have a couple of options for prompts. The first is to write a simple wrapper around dmenu/bemenu. The second is to use guile-cairo to draw prompts we need. I'm partial to the former, but we'll eventually need the latter for drawing stuff like tabs. (If cairo is involved, this is no longer low-hanging fruit).

What I'd like is something like:

(define-key! default-keymap (kbd "M-j") (lambda () (switch-to-workspace (prompt "Workspace: "))))

Bonus points for auto completion.

This will involve three main changes:

• Logic in (gram lib render-hooks) to know whether to place a view in a layout or the floating layer
• Adding support for pointer/window interaction in the C core.
• Adding the ability to bind mouse buttons to functionality (this will allow binding e.g. Mouse1 drag to floating layer motion)

Presently, if a hook wants to signal that the focused view should not receive the next key press, it needs to call (swallow-next-key). The default keymap function does this. However, it does not allow for functions to conditionally override it.

For example, I would like to be able to bind Mouse to view-focus but have the key passed on to the target view if the view is already focused. One way to do this would be to change define-key! to be syntax-case instead of a single define-syntax-rule and then add an extra parameter that acts as a predicate deciding when to swallow the key (default is constantly true). Not sure if this is the best way to do it.

These should be added in under the (gram lib *) namespace and support up/down/left/right motion via zippers. Motion should update view focus.

This should be a pretty simple wrapper around the go-* zipper functions in (gram lib zipper).

Currently, layouts are nestable but there is no way to actually nest them on the user's end. This should be pretty straightforward to implement using the swap function in (gram lib zipper) (e.g. (swap z layout-fn) I think).

This occurs when inserting new windows and when resizing existing ones. It is unclear whether this is caused by my testing setup (running the compositor inside an X instance), the compositor, or my code (the pass between guile and C isn't free).

If you watch closely, you can see the same tearing on insert with XMonad, which leads me to believe that we just need a way to queue actions for the next frame instead of having them occur immediately.

However, the resize tearing is new to me and needs to be investigated.

I am currently writing a package definition to build gram with the guix package manager. It would be helpful to know under what license terms the package can be released in case it should build one day.

./configure: line 4157: syntax error near unexpected token GUILE,' ./configure: line 4157: PKG_CHECK_MODULES(GUILE, guile-2.0)'

Presently, the hook error handling method only prints the error that was thrown with its arguments. It would be much more helpful if it also printed the stack trace.

For this, I believe it is only necessary to add a pre-unwind handler that prints the stack (should be a guile builtin for that).

Related: Cloudef/wlc#67

It is extremely difficult to test any behavior related to views/outputs (such as, idk, resource management?) with the dependency on a graphical context and external programs.

Moving left/right and up is natural and easy to do without any extra mechanics. Left/right move the focus within the current layout, and up raises the focus to the parent layout. However, moving things down requires extra work.

The best way I've seen it done is with a mark-and-move system, where the user marks the objects of interest, and then moves them to the desired layout (or kills them, or hides them, or whatever).

This is a continuation of issue #3 because it is out of scope of what I originally intended for that issue to represent.

Presently, comment/docstring quality is incredibly low. There is no excuse for this. We need:

• Good code comments describing the (often intricate) C<->SCM interactions
• Good docstrings (SCM) to improve UX
• Probably an info manual would be good (I <3 my C-h i) and basic man page at the least.

Present status: very little test coverage.

Partial dependency on #1.

Covering scm will be easier to start with than covering more C until #1 is done.

If view-focus is bound to a key, the cursor focus becomes out of sync with what the user expects. To fix this, we probably need a wrapper around view-focus that updates the zipper's focus.

Additionally, dragging does not switch focus to the floating layer (unless it was already there).

Possibly a bit early to think about workspaces since I only just got layouts going, but after sleeping on it I think they will be straightforward to implement on the scheme end, with only minor work on the C end.

Currently, layouts are implemented as an alist of (Output . Layout) pairs. Workspaces are conceptually an alist of (Name . Layout) pairs (or just a list of Layouts if you don't want naming).

A simple way to implement workspaces would be to have a workspace alist that contains at least as many entries as there are outputs with the ability to swap the current layout on an output with one from the workspace list.

The render engine could be modified to use an (Output . Name) alist instead of a (Output . Layout) one in order to keep only one canonical representation.

On the C end, we need the ability to remove views from an output and hide them altogether. This should be a straightforward wrapper around wlc functionality.

Window spacing will be an easy layout wrapper, but borders (e.g. with fixed color) are another matter entirely.

See orbment's crappy_borders plugin for an example