Gabriel Arazas
edd5fc2f2a
Even though it might not on a working config. The best option is just allowing to have a system-wide config which is yet to be implemented in the extension. Might have to make a discussion about it. |
||
---|---|---|
.. | ||
a-happy-gnome | ||
knome | ||
default.nix | ||
README.adoc |
These are where my workflows are defined and configured. Basically, workflows are mainly graphical sessions concerned with aesthetics and impose a structured way of using things, this may include Unix rices and good 'ol reliable desktop configurations like my GNOME config. This is where modules will define how you’re going to interact with the computer whether you should use something ranging from a full-fledged desktop environment with bells and whistles to a minimalist desktop environment only composing of a window manager, a terminal, and a bar.
Design constraints
The following list is the summary which can also serve as a guideline to developing a workflow module.
-
All workflow modules should be enabled through
workflows.enable
option containing the names of the workflows to be used.= -
While there is no convention for naming workflow modules, they are mostly expected to be enabled with a reverse DNS-like scheme (e.g.,
workflows.enable = [ "one.foodogsquared.MoseyBranch" ]
). This is mainly to easily create custom desktop sessions where they are typically named this way. -
Custom themes should be configured in
workflows.workflows
namespace (e.g.,options.workflows.workflows.a-happy-gnome
,options.workflows.workflows.simple-way
). This is expected to contain options specific for that workflow module such as an extra list of applications to be installed, additional extensions, and hardware-specific options. -
No configuring display managers or localization. This is expected more to be configured by the user themselves and it makes the workflow modules more composable.