Skip to content
This repository was archived by the owner on May 15, 2021. It is now read-only.
Akira Komamura edited this page Jun 11, 2018 · 4 revisions

Table of contents

Design Goals

The goal of frame-workflow is to provide a framework to make your work (or possibly even life) flow flawlessly. At least it should provide effective help with that.

This section describes features frame-workflow needs to implement to achieve the goal. It does not mean the current version has all of the features listed in here, but they will be implemented in the meantime.

Each frame dedicates to one purpose

For simplicity, each frame should be dedicated to one task. This is useful for the following reasons:

  • Frames are visible and concrete.
  • Each frame can have a set of states as frame parameters.
  • Each frame can have a history of layout with winner-mode.

Frame-purpose lets you focus on particular things in frame-oriented workflow. Frame-workflow should be integrated with it.

Named workspaces

This is a problem with EXWM and was solved by framegroups.el. Frame-workflow needs to reimplement most of framegroups. It may or may not need further enhancements for integration with EXWM.

Per-frame actions

Frame-workflow allows you to define per-frame actions, and they can be persisted across sessions.

Optional stateful workflow

Although each frame is usually responsible for a single task, it may sometimes be useful to maintain a sub-state in it. Frame-workflow supports this feature. Each frame has an observer object that can hold user-defined states, and you can use the states to indicate your task-specific work status. A summary of the states is displayed on the mode line. This is optional, and you don’t have to explicitly define states for all of your task contexts.

Clone this wiki locally