124 lines
4.3 KiB
Markdown
124 lines
4.3 KiB
Markdown
|
|
|
|
I plan on using these deadlines for the project (in week numbers from 11th May)
|
|
|
|
*Write about researching stuff here.
|
|
|
|
1. identify suitable stakeholders and describing them, explaining how they use features of existing solutions.
|
|
|
|
2. existing solutions.
|
|
|
|
3. basing requirements list from these.
|
|
|
|
4. cross comparision with i3 awsome etc.
|
|
|
|
5. demographic, income (if they can buy the needed hardware)
|
|
|
|
6. background of expected users.
|
|
|
|
7. design bit next.
|
|
|
|
8. justify each feature.
|
|
|
|
9. do priorities of requirements.
|
|
|
|
10. and therefore remove bits like that.
|
|
|
|
11. write about hardware available and compare those.
|
|
|
|
12. about me able to support anything (hardwarewise).
|
|
|
|
13. what the hardware limits can be.
|
|
|
|
14. the fact that i haven't followed 100% of the standard.
|
|
|
|
15.
|
|
|
|
|
|
|
|
# EPQ
|
|
|
|
- Do project Q journal.
|
|
|
|
|
|
|
|
## Add a source eval table journal entry.
|
|
|
|
source, type (primary - docs etc., secondary - blog etc.), author/crdibility, currency (date) & relevance, bias, how I used it.
|
|
|
|
### Source Types
|
|
|
|
1. Official: I've considered sources directly from the original developers, their websites or official docs of a project/program as primary sources.
|
|
2. Unofficial: Blogposts, articles, guides etc. are classified as secondary.
|
|
|
|
### Crdibility
|
|
|
|
I have decided to count credibility of a source based on how acedemic it is or if it is for statistics / metrics about the authors personal biases or how outdated the resource is.
|
|
|
|
### Usage
|
|
|
|
I put a little note of how the resource was useful to my project and where I used it.
|
|
|
|
### Table.
|
|
|
|
| Index | Source (Address) | Type | Author | Credibility | Date | Usage |
|
|
| --- | --- | --- | --- | --- | --- | --- |
|
|
|
|
### References.
|
|
|
|
(A list of proper harvard style references for each resource.)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Add an entry for researching into stakeholders.
|
|
|
|
### Target users
|
|
|
|
The window manager is aimed at advanced Linux users who want to control their workflow through code rather than a fixed configuration file.
|
|
|
|
### Stakeholder 1: Keyboard-driven tiling WM users
|
|
|
|
Users of window managers such as `i3`, `bspwm` or `dwm` who are comfortable in a terminal, edit their configuration by hand and control most of their desktop from the keyboard.
|
|
|
|
These users already bind keys to launch programs and move windows, but they are limited to the commands the WM provides. With this window manager they could write their own behaviour, such as a keybind that cycles through windows of the same application, or a rule that automatically moves new terminal windows to a particular workspace.
|
|
|
|
### Stakeholder 2: Developers and sysadmins who work remotely
|
|
|
|
Users who regularly connect to remote servers over SSH and sometimes run graphical applications on them through X11 forwarding. I am part of this group, so I can also act as a source of requirements here.
|
|
|
|
They would run the window manager locally and expect forwarded applications to behave like any other window: placed, tiled, focused and moved between workspaces. They could also script context-specific layouts, for example a keybind that opens a terminal and an editor side by side for a particular project.
|
|
|
|
X11 compatibility (which is why I chose X11 over Wayland), workspaces to separate projects or machines, reliable focus handling and fast response to input.
|
|
|
|
Stability matters most to this group. If the window manager crashes, they lose their whole graphical session, including any forwarded applications. A mistake in a script should be reported clearly without taking the session down.
|
|
|
|
Since the project is aimed at advanced users, I am not providing a graphical settings tool, panels or a taskbar, and I do not plan to support minimised windows. These are the responsibilities of a desktop environment rather than a basic window manager, and the stakeholders above are comfortable working without them.
|
|
|
|
They can script these features in using my api and other libraries if they want however.
|
|
|
|
|
|
|
|
|
|
## Add an entry for X11 vs Wayland
|
|
|
|
## Then add an entry for my ruby prototype.
|
|
|
|
## Then add an entry for my haskell prototype.
|
|
|
|
## Then an entry on research into ocaml
|
|
|
|
## Then an entry to do with the fact that ive started working on with ocaml
|
|
|
|
## Then an entry about nix & git & dune build stuff.
|
|
|
|
## Then an entry for mruby library, and maybe one for xcb.
|
|
|
|
## Then add entries for approximately every git commit ive made in the main project.
|
|
|
|
## Then add entries for writeup draft 1 etc.
|
|
|