Skip to content

17th March 2023

Life Management

Task Management

Getting Things Done

  • New: Define the Todo list.

    This list contains all the next actions and projects you are going to actively work on. Projects are any desired result that can be accomplished within a year that requires more than one action step. This means that some rather small things you might not normally call projects are going to be on your Projects list, as well as some big ones. If one step won’t complete something, some kind of goalpost needs to be set up to remind you that there’s something still left to do. If you don’t have a placeholder to remind you about it, it will slip back into your head. The reason for the one-year time frame is that anything you are committed to finish within that scope needs to be reviewed weekly to feel comfortable about its status. Another way to think of this is as a list of open loops, no matter what the size. This is going to be one of the lists that you'll review more often, and it needs to be manageable, if the items start to grow you may want to track the elements you want to do in the semester, or trimester.

    Projects do not initially need to be listed in any particular order, by size, or by priority. They just need to be on a master list so you can review them regularly enough to ensure that appropriate next actions have been defined for each of them. That being said, I like to order them a little bit so that I don't need to read the whole list to choose what to do.

    There may be reasons to sort your projects into different subcategories, based upon different areas of your focus, but initially creating a single list of all of them will make it easier to customize your system appropriately as you get more comfortable with its usage. To sort them use tags instead of hierarchical structures, they are more flexible. For example you could use tags for:

    • Context: Where can you do the element: home, computer, mobile, ...
    • Area: Broad categories where the element falls in: activism, caring, self-caring, home, digital services, ...
    • Type: I like to separate the tasks that are meant to survive (maintenance) from the ones that are meant to improve things (improvement)
    • Mood, energy level, time: It's useful to have a quick way to see the tasks you can work on when you don't have that much time (small), you don't have that much mental energy (brainless), when you're sad, ...

    For many of your projects, you will accumulate relevant information that you will want to organize by theme or topic or project name. Your Projects list will be merely an index. All of the details, plans, and supporting information that you may need as you work on your various projects should be contained in your References system.

  • New: Define the calendar.

    The calendar holds reminders of actions you need to take fall into two categories: those about things that have to happen on a specific day or time, and those about things that just need to get done as soon as possible. Your calendar handles the first type of reminder.

    These things go on your calendar:

    • Time-Specific actions or appointments.
    • Day-Specific actions: These are things that you need to do sometime on a certain day, but not necessarily at a specific time.
    • Day-Specific information: Information that may be useful on a certain date. This might include directions for appointments, activities that other people will be involved in then, or events of interest. It’s helpful to put short-term tickler information here, too, such as a reminder to call someone after he or she returns from vacation. This is also where you would want to park important reminders about when something might be due, or when something needs to be started, given a determined lead time.

    Daily to-do lists don't belong to the calendar because:

    • Constant new input and shifting tactical priorities reconfigure daily work so consistently that it’s virtually impossible to nail down to-do items ahead of time. Having a working game plan as a reference point is always useful, but it must be able to be renegotiated at any moment. Trying to keep a list on the calendar, which must then be reentered on another day if items don’t get done, is demoralizing and a waste of time. The Next Actions lists will hold all of those action reminders, even the most time-sensitive ones. And they won’t have to be rewritten daily.

    • If there’s something on a daily to-do list that doesn’t absolutely have to get done that day, it will dilute the emphasis on the things that truly do. The calendar should be sacred territory. If you write something there, it must get done that day or not at all.

    That said, there’s absolutely nothing wrong with creating a quick, informal, short list of “if I have time, I’d really like to . . .” kinds of things, picked from your Next Actions inventory. It just should not be confused with your “have-tos,” and it should be treated lightly enough to discard or change quickly as the inevitable surprises of the day unfold.

  • New: Give an overview of how I'm using gtd.

    Before you start moving stuff around it's a good idea to get the first design of your whole system, in my case I'm going to heavily rely on org-mode to track most of the stuff with a repository with the next structure:

    .
    ├── calendar
    │   ├── personal.org
    │   │   ├── One time events
    │   │   ├── Recurring events
    │   │   ├── Birthdays
    │   │   └── Deathdays
    │   ├── day.org
    │   ├── tickler.org
    │   ├── work_1.org
    │   ├── work_2.org
    │   ├── partner.org
    │   ├── family.org
    ├── inbox
    │   ├── computer.org
    │   ├── mobile.org
    │   └── tablet.org
    ├── reference
    │   ├── blue
    │   ├── reference.org
    │   └── red
    └── todo
        ├── personal.org
        ├── work_1.org
        ├── work_2.org
        └── someday.org
    

    Where:

    • The subtrees behind the .org files are the heading trees.
    • All org files go with their respective org_archive ones, they're not shown in the above diagram to keep it simple.
    • calendar/personal.org is my personal calendar.
    • calendar/day.org is my day planner.
  • New: Define how to use the Personal calendar.

    The calendar/personal.org file holds:

    • Appointments: Meant to be used for elements of the org file that have a defined date to occur. You whether do it that date or not do it at all. Avoid using dates to organize your tasks and if you don't do it that day, reschedule it to another date, it's a waste of time, use next actions in your todo instead. If you need to act on it use a TODO element, otherwise a headline is enough An example would be.
    * TODO Meet with Marie
    <2023-02-24 Fri>
    
    * Internet's birthday
    <2023-03-13 Mon>
    
    • Recurring events: Events that not only happen on the given date, but again and again after a certain interval of N hours (h), days (d), weeks (w), months (m), or years (y). The following shows up in the agenda every Wednesday:
    * TODO Go to pilates
      <2007-05-16 Wed 12:30 +1w>
    

    Each section has it's own tag: :recurring:, :day:, :birthday:, :deathday:, and the whole file has the :event: tag for easy filtering.

    In rare cases you may want to use the DEADLINE property if you want to be warned in the agenda some days before the date arrives or the SCHEDULED one in case you want to see in the agenda when you start working on the task. Again, don't waste time postponing these dates, if you do, you're using the system wrong.

  • New: Define how to use the Day planner.

    Some of my day events are semi-regular, meaning that the recurrence options are not powerful enough. For example, I usually go to pilates on Tuesdays, but some weeks I go at 18:00 and others at 19:00. In the past I used a script that interacts with ikhal to create the elements of the day based on some questionary. The idea is to migrate the tool to create appointments in the day under the diary.org file using a datetree structure:

    * 2010
    ** 2010-12 December
    *** 2010-12-20 Tuesday
    **** TODO Go to pilates
        <2010-12-20 Tue 19:00-20:00>
    

    I also use this file to add any diary annotations for my life log. Once this issue is solved it will be really easy to add diary thoughts through the capture feature

  • New: Define how to use the todo files.

    The todo files are where you track the todo list, which holds your projects and their next steps to work on. The todo/personal.org, todo/work_1.org and todo/work_2.org files of the above schema will be divided into these level 1 headings:

    • * Necessary: These projects need to be dealt with immediately and finished as soon as possible
    • * Desirable: Here is where most of your elements will be, these are the ones that you think it's important to work on but there is no hard pressure.
    • * Optional: These are the projects that it would be nice to work on, but if you don't it's fine.

    Projects are any the second level headings with TODO keywords. To see the list of your projects just fold all the items in the todo.org file.

    Inside each section the elements are more less ordered by what I want to work on first. But all projects are actionable, so if I'm not in the mood to do the first ones, I tackle the rest. As such, I try not to spend too much time ordering them.

    I find useful to split the tasks between my life silos, so that I don't even have a chance to think of anything of work_1 when I'm doing my personal stuff or work_2 stuff.

  • New: Define how to work with projects.

    Given the broad definition of what we consider a project and how they are usually cooked, the system that represents it must be equally flexible, quick to interact with and easy to evolve.

    Every project starts with the title:

    * TODO Improve task management system
    

    Optionally you can add a description

    * TODO Improve task management system
      Using Openprojects is uncomfortable, I need to find a better system.
    

    You may have noticed that the description doesn't follow the rules we defined for next actions, that's fine as you don't act on projects, but on their underlying actions. Nevertheless I like to start them with a verb. It may even make sense not to use TODO items but simple headings to define your projects. On one side you don't act on projects so it would make sense to use headings, on the other, it's also interesting to know the project state, which can be easily tracked with the TODO keywords. If you could tell apart headings from TODO items in the agenda views it would make sense to use them. Right now nvim-orgmode let's you select in the agenda views only TODO items or TODO and headings, but you can't select only headings, so at the moment I don't see any good reason not to use TODO items for the projects.

    To define the next actions of a project you can use checklists

    * TODO Improve task management system
      - [-] Read David Allen's GTD book
        - [x] Read chapters 6 and 7
        - [ ] Read chapters 8 and 9
      - [ ] Sum up the book in the blue book
    

    As your checklists grow they may start to be uncomfortable, for example if it has:

    • More than two levels of indentation: It may be hard to follow the logic of the task structure.
    • A lot of elements: You can't archive parts of checklists, so as you complete elements, they will still be shown diverting your attention from the things you can actually act upon or making you loose time scrolling to find where they are.

    In these cases it makes sense to promote the first level of headings to subprojects:

    * TODO Improve task management system
      * DOING Read David Allen's GTD book
        - [x] Read chapters 6 and 7
        - [ ] Read chapters 8 and 9
      * TODO up the book in the blue book
    

    That way when Read David Allen's GTD book is done, you can archive it and forget about it.

    If the project starts having many subprojects, it may help to have a section "Outcomes" to define what do you want to achieve with the project. It can be accompanied with a "Next Steps" section to add any subproject or action that doesn't match the defined outcomes, and once you finish the project, you can refile them into new projects.

  • New: The NEXT state.

    It's useful to have a NEXT state to track the first next action you need to deal with for each project. That way when you open the file, you can go to the top of it and search for NEXT and it will lead you directly to where you need to work on.

  • New: Define how to manage tags.

    As explained in the todo list section, you can use tags to filter your tasks. I'm using the next ones:

    • Area: Broad categories where the element falls in: activism, caring, self-caring, home, digital services, ...
    • Type: I like to separate the tasks that are meant to survive (maintenance) from the ones that are meant to improve things (improvement). I use these only in the big projects.
    • :long_break:: I'm using this tag to track the small projects that can be done in the long pomodoro breaks. Depending on the kind of long break that I need I then filter for the next tags:
    • brainless: If I want to keep on thinking on what I was doing, an example could be emptying the dishwasher, watering the plants, ...
    • call: If I want to completely change context and want some social interaction. For example call mom.
  • New: Define how to manage waiting tasks.

    Waiting actions are elements that are blocked for any reason. I use the WAITING TODO keyword to track this state. Under each element you should add that reason and optionally the process you want to follow to unblock it.

    If you need to actively track the evolution of the WAITING status, leave it on the top of your todo. Otherwise set the date you want to check its status and move it to the ticker.org file.

  • New: Define how to use the tickler.

    The tickler is a system where you postpone actions to a specific date, but not with a calendar mindset where the action needs to be done at that date. With the tickler you schedule the action to enter your inbox that day to decide what are you going to do with it.

    To implement this in orgmode you can add the :tickler: tag to any element that is tracked in the agenda files and once a day you can look at the day's agenda and decide what to do with the action. It's important though that whatever you do with it, you have to remove it from the agenda view in order to only keep the elements that you need to do in the day. You can follow this workflow by:

    • Opening the agenda view gaa
    • Go to the view of the day vd
    • Go to today .
    • Search by tickler /tickler

    It can also help to review in the weeklies all the ticklers of the week to avoid surprises.

    If you want to make the project go away from your todo or someday until the tickler date, move it to the tickler.org file.

  • Correction: Keep on defining steps to capture all your stuff.

    As you engage in the capturing step, you may run into one or more of the following problems:

    • An item is too big to go in the in-tray: create a post it that represents it or add it as an entry in your digital inbox. If you can, add the date too
    • The pile is too big to fit the in-tray: Create visually distinct stacks around the in-tray, even on the floor.
    • Doubts whether to trash something: When in doubt keep it, you'll decide about it later when you process the in-tray. What you need to avoid is to get caught up in deciding what to do with the element. That's going to be the next step in the process, let's go one at a time.
    • Getting caught up in cleaning and organizing: If it doesn't take that long it's fine but remember the purpose of this process and the fact that we want to finish it as soon as possible. If you discover things you want to change, add them to the in-tray.
    • If you encounter stuff that is already on lists and organizers, treat them as everything else in the "in".

    Now that the process it's clear let's start.

    Start with the space where you actually do stuff, scan the place centimeter by centimeter with the mindset defined above, check your desk, drawers, floors, walls, shelves, equipment, furniture, fixtures...Then repeat the process with each room of your home.

  • New: Explain how to capture all your mental stuff.

    Once you already have a nice pile of stuff, think of what has your attention that isn’t represented by something already in your in-tray and record each thought, each idea, each project or thing that occurs you and add it to the inbox.

    To assist in clearing your head, you may want to review the following the next trigger list, item by item, to see if you’ve forgotten anything.

  • New: Define priorities from A to D.

    I feel more comfortable with these priorities:

    • A: Critical
    • B: High
    • C: Normal
    • D: Low

    This gives you room to usually work on priorities B-D and if something shows up that is really really important, you can use A. You can set this setting with the next snippet:

    require('orgmode').setup({
      org_priority_highest = 'A',
      org_priority_default = 'C',
      org_priority_lowest = 'D',
    })
    
  • New: Warn against using DEADLINE.

    Using too many tasks with a DEADLINE will clutter your agenda. Use it only for the actions that you need to have a reminder, instead try to using appointment dates instead.

    If you need a different warning period for a special task, you can specify it. For example setting a warning period of 5 days DEADLINE: <2004-02-29 Sun -5d>. To configure the default number of days add:

    require('orgmode').setup({
      org_deadline_warning_days = 10,
    })
    
  • Correction: Improve how to use tags.

    When you press the tag key binding you can type:

    • tag1: It will add :tag1:.
    • tag1:tag2: It will add :tag1:tag2:.
    • Press ESC: It will remove all tags from the item.

    Tags make use of the hierarchical structure of outline trees. If a heading has a certain tag, all subheadings inherit the tag as well. For example, in the list

    * Meeting with the French group      :work:
    ** Summary by Frank                  :boss:notes:
    *** TODO Prepare slides for him      :action:
    

    The final heading has the tags work, boss, notes, and action even though the final heading is not explicitly marked with those tags. You can also set tags that all entries in a file should inherit just as if these tags were defined in a hypothetical level zero that surrounds the entire file. Using a line like the next one:

     #+FILETAGS: :Peter:Boss:Secret:
    
  • New: How to use links.

    One final aspect of the org file syntax are links. Links are of the form [[link][description]], where link can be an:

    A link that does not look like a URL refers to the current document. You can follow it with gx when point is on the link (Default <leader>oo) if you use the next configuration.

    org = {
      org_open_at_point = 'gx',
    }
    
  • New: Internal document links.

    Org provides several refinements to internal navigation within a document. Most notably:

    • [[*Some section]]: points to a headline with the name Some section.
    • [[#my-custom-id]]: targets the entry with the CUSTOM_ID property set to my-custom-id.

    When the link does not belong to any of the cases above, Org looks for a dedicated target: the same string in double angular brackets, like <<My Target>>.

    If no dedicated target exists, the link tries to match the exact name of an element within the buffer. Naming is done, unsurprisingly, with the NAME keyword, which has to be put in the line before the element it refers to, as in the following example

     #+NAME: My Target
    | a  | table      |
    |----+------------|
    | of | four cells |
    

    Ultimately, if none of the above succeeds, Org searches for a headline that is exactly the link text but may also include a TODO keyword and tags, or initiates a plain text search.

    Note that you must make sure custom IDs, dedicated targets, and names are unique throughout the document. Org provides a linter to assist you in the process, if needed, but I have not searched yet one for nvim.

  • New: How to use properties.

    Properties are key-value pairs associated with an entry. They live in a special drawer with the name PROPERTIES. Each property is specified on a single line, with the key (surrounded by colons) first, and the value after it:

    * CD collection
    ** Classic
    *** Goldberg Variations
        :PROPERTIES:
        :Title:     Goldberg Variations
        :Composer:  J.S. Bach
        :Publisher: Deutsche Grammophon
        :NDisks:    1
        :END:
    

    You may define the allowed values for a particular property Xyz by setting a property Xyz_ALL. This special property is inherited, so if you set it in a level 1 entry, it applies to the entire tree. When allowed values are defined, setting the corresponding property becomes easier and is less prone to typing errors. For the example with the CD collection, we can pre-define publishers and the number of disks in a box like this:

    * CD collection
      :PROPERTIES:
      :NDisks_ALL:  1 2 3 4
      :Publisher_ALL: "Deutsche Grammophon" Philips EMI
      :END:
    

    If you want to set properties that can be inherited by any entry in a file, use a line like:

     #+PROPERTY: NDisks_ALL 1 2 3 4
    

    This can be interesting for example if you want to track when was a header created:

    *** Title of header
       :PROPERTIES:
       :CREATED: <2023-03-03 Fri 12:11>
       :END:
    
  • New: How to do Agenda searches.

    When using the search agenda view you can:

    • Search by TODO states with /WAITING
    • Search by tags +home. The syntax for such searches follows a simple boolean logic:

    • |: or

    • &: and
    • +: include matches
    • -: exclude matches

    Here are a few examples:

    • +computer&+urgent: Returns all items tagged both computer and urgent.
    • +computer|+urgent: Returns all items tagged either computer or urgent.
    • +computer&-urgent: Returns all items tagged computer and not urgent.

    As you may have noticed, the syntax above can be a little verbose, so org-mode offers convenient ways of shortening it. First, - and + imply and if no boolean operator is stated, so example three above could be rewritten simply as:

    +computer-urgent
    

    Second, inclusion of matches is implied if no + or - is present, so example three could be further shortened to:

    computer-urgent
    

    Example number two, meanwhile, could be shortened to:

    computer|urgent
    

    There is no way (as yet) to express search grouping with parentheses. The and operators (&, +, and -) always bind terms together more strongly than or (|). For instance, the following search

    computer|work+email
    

    Results in all headlines tagged either with computer or both work and email. An expression such as (computer|work)&email is not supported at the moment. You can construct a regular expression though:

    +{computer\|work}+email
    
    • Search by properties: You can search by properties with the PROPERTY="value" syntax. Properties with numeric values can be queried with inequalities PAGES>100. To search by partial searches use a regular expression, for example if the entry had :BIB_TITLE: Mysteries of the Amazon you could use BIB_TITLE={Amazon}
  • New: How to use Capture in orgmode.

    Capture lets you quickly store notes with little interruption of your work flow. It works the next way:

    • Open the interface with ;c (Default <leader>oc) that asks you what kind of element you want to capture.
    • Select the template you want to use. By default you only have the Task template, that introduces a task into the same file where you're at, select it by pressing t.
    • Fill up the template.
    • Choose what to do with the captured content:
    • Save it to the configured file by pressing ;w (Default <control>c)
    • Refile it to a file by pressing ;r (Default <leader>or).
    • Abort the capture ;q (Default <leader>ok).
    mappings = {
      global = {
        org_capture = ';c',
        },
      capture = {
        org_capture_finalize = ';w',
        org_capture_refile = ';r',
        org_capture_kill = ';q',
      },
    }
    
  • New: Configure the capture templates.

    Capture lets you define different templates for the different inputs. Each template has the next elements:

    • Keybinding: Keys to press to activate the template
    • Description: What to show in the capture menu to describe the template
    • Template: The actual template of the capture, look below to see how to create them.
    • Target: The place where the captured element will be inserted to. For example ~/org/todo.org. If you don't define it it will go to the file configured in org_default_notes_file.
    • Headline: An optional headline of the Target file to insert the element.

    For example:

    org_capture_templates = {
      t = { description = 'Task', template = '* TODO %?\n  %u' }
    }
    

    For the template you can use the next variables:

    • %?:Default cursor position when template is opened
    • %t: Prints current date (Example: <2021-06-10 Thu>)
    • %T: Prints current date and time (Example: <2021-06-10 Thu 12:30>)
    • %u: Prints current date in inactive format (Example: [2021-06-10 Thu])
    • %U: Prints current date and time in inactive format (Example: [2021-06-10 Thu 12:30])
    • %<FORMAT>: Insert current date/time formatted according to lua date format (Example: %<%Y-%m-%d %A> produces 2021-07-02 Friday)
    • %x: Insert content of the clipboard via the "+" register (see :help clipboard)
    • %^{PROMPT|DEFAULT|COMPLETION...}: Prompt for input, if completion is provided an :h inputlist will be used
    • %(EXP): Runs the given lua code and inserts the result. NOTE: this will internally pass the content to the lua load() function. So the body inside %() should be the body of a function that returns a string.
    • %f: Prints the file of the buffer capture was called from.
    • %F: Like %f but inserts the full path.
    • %n: Inserts the current $USER
    • %a: File and line number from where capture was initiated (Example: [[file:/home/user/projects/myfile.txt +2]])

    For example:

    {
      T = {
        description = 'Todo',
        template = '* TODO %?\n %u',
        target = '~/org/todo.org'
      },
     j = {
        description = 'Journal',
        template = '\n*** %<%Y-%m-%d %A>\n**** %U\n\n%?',
        target = '~/sync/org/journal.org'
      },
      -- Nested key example:
      e =  'Event',
      er = {
        description = 'recurring',
        template = '** %?\n %T',
        target = '~/org/calendar.org',
        headline = 'recurring'
      },
      eo = {
        description = 'one-time',
        template = '** %?\n %T',
        target = '~/org/calendar.org',
        headline = 'one-time'
      },
      -- Example using a lua function
      r = {
        description = "Repo URL",
        template = "* [[%x][%(return string.match('%x', '([^/]+)$'))]]%?",
        target = "~/org/repos.org",
      }
    }
    
  • New: Synchronize with external calendars.

    You may want to synchronize your calendar entries with external ones shared with other people, such as nextcloud calendar or google.

    The orgmode docs have a tutorial to sync with google and suggests some orgmode packages that do that, sadly it won't work with nvim-orgmode. We'll need to go the "ugly way" by:

  • New: Comparison with Markdown.

    What I like of Org mode over Markdown:

    • The whole interface to interact with the elements of the document through key bindings:
    • Move elements around.
    • Create elements
    • The TODO system is awesome
    • The Agenda system
    • How it handles checkboxes <3
    • Easy navigation between references in the document
    • Archiving feature
    • Refiling feature
    • # is used for comments.
    • Create internal document links is easier, you can just copy and paste the heading similar to [[*This is the heading]] on markdown you need to edit it to [](#this-is-the-heading).

    What I like of markdown over Org mode:

    • The syntax of the headings ## Title better than ** Title. Although it makes sense to have # for comments.
    • The syntax of the links: [reference](link) is prettier to read and write than [[link][reference]], although this can be improved if only the reference is shown by your editor (nvim-orgmode doesn't do his yet)

OpenProject

  • Correction: Suggest not to use openproject.

    I've decided to use orgmode instead.

Coding

Languages

Click

  • New: File system isolation.

    You may need to isolate the environment variables if your application read the configuration from them. To do that override the runner fixture:

    @pytest.fixture(name="runner")
    def fixture_runner() -> CliRunner:
        """Configure the Click cli test runner."""
        return CliRunner(
            env={
                'PASSWORD_STORE_DIR': '',
                'GNUPGHOME': '',
                'PASSWORD_AUTH_DIR': '',
            },
            mix_stderr=False
        )
    

    If you define the fixture in conftest.py you may need to use another name than runner otherwise it may be skipped, for example cli_runner.

Python Snippets

  • New: Substract two paths.

    It can also framed to how to get the relative path between two absolute paths:

    >>> from pathlib import Path
    >>> p = Path('/home/lyz/')
    >>> h = Path('/home/')
    >>> p.relative_to(h)
    PosixPath('lyz')
    

DevOps

Continuous Integration

Mypy

  • New: Module "typing" has no attribute "Annotated".

    This one happens only because annotated is not available in python < 3.9.

    try:
        # mypy is complaining that it can't import it, but it's solved below
        from typing import Annotated # type: ignore
    except ImportError:
        from typing_extensions import Annotated
    

Operating Systems

Linux

Linux Snippets

  • New: Get class of a window.

    Use xprop and click the window.

    Get the current brightness level with cat /sys/class/backlight/intel_backlight/brightness. Imagine it's 1550, then if you want to lower the brightness use:

    sudo echo 500 > /sys/class/backlight/intel_backlight/brightness
    

aleph

i3wm

  • New: Move the focus to a container.

    Get the container identifier with xprop and then:

    i3-msg '[title="khime"]' focus
    i3-msg '[class="Firefox"]' focus
    
  • New: Interact with Python.

    Install the i3ipc library:

    pip install i3ipc
    

    Create the connection object:

    from i3ipc import Connection, Event
    
    i3 = Connection()
    

    Interact with i3:

    focused = i3.get_tree().find_focused()
    print('Focused window %s is on workspace %s' %
          (focused.name, focused.workspace().name))
    
    outputs = i3.get_outputs()
    
    print('Active outputs:')
    
    for output in filter(lambda o: o.active, outputs):
        print(output.name)
    
    i3.command('focus left')
    
    for container in i3.get_tree().find_fullscreen():
        container.command('fullscreen')
    
    root = i3.get_tree()
    print(root.name)
    for con in root:
        print(con.name)
    
    def on_workspace_focus(self, e):
        # The first parameter is the connection to the ipc and the second is an object
        # with the data of the event sent from i3.
        if e.current:
            print('Windows on this workspace:')
            for w in e.current.leaves():
                print(w.name)
    
    def on_window_focus(i3, e):
        focused = i3.get_tree().find_focused()
        ws_name = "%s:%s" % (focused.workspace().num, focused.window_class)
        i3.command('rename workspace to "%s"' % ws_name)
    
    i3.on(Event.WORKSPACE_FOCUS, on_workspace_focus)
    i3.on(Event.WINDOW_FOCUS, on_window_focus)
    
    i3.main()
    

Other

  • Correction: Update introduction.

    The method was described by David Allen in a book with the same name. It's clear that the book is the corner stone of David's business. He is selling his method on every word, some times to the point of tiresome. It's also repeats the same ideas on different parts of the book, I guess that's good in terms of sticking an idea in the people's mind, but if you're already convinced and are trying to sum up the book it's like, hey, I have 90% of the valuable contents of this chapter already in my summary. It's obvious too the context of the writer, that the book was written a while ago and who does it write to. It talks quite often about assistants, bosses of high firm companies he's helped, preferring low-tech physical solutions over digital ones, a lot of references about parenting... If you're able to ignore all the above, it's actually a very good book. The guy has been polishing the method for more than 30 years, and has pretty nice ideas that can change how you manage your life.

    My idea of this summary is to try to extract the useful ideas removing all those old-fashioned capitalist values from it.

  • New: Guides on processing your inbox.

    Remember to follow the next rules while processing the items:

    • Process the top item first: that way you treat each element equally, so the "least" important ones are not left dangling forever in your inbox thus thwarting it's purpose.
    • Process one item at a time.
    • Never put anything back into “in.”

    For each element you need to ask yourself: "What's the next action?".

  • New: How to clarify your inbox items.

    If you can do something about the element, you need to think which is the next physical, visible activity that would be required to move the situation towards closure. It's tricky, something like "set meeting" won't do because it's not descriptive of physical behaviour. There is still stuff to decide how, when, with whom, if you don't do it now you won't empty your head and the uncertainty will create a psychological gap that will make you procrastinate, so define the next action now. "Decide what to do about X" doesn't work either, you may need to gather more information on the topic, but deciding doesn't take time.

    Once you have the next action, if it can be done in two minutes or less, do it when you first pick the item up. Even if it is not a high-priority one, do it now if you’re ever going to do it at all. The rationale for the two-minute rule is that it’s more or less the point where it starts taking longer to store and track an item than to deal with it the first time it’s in your hands. Two minutes is just a guideline. If you have a long open window of time in which to process your in-tray, you can extend the cutoff for each item to five or ten minutes. If you’ve got to get to the bottom of all your input rapidly, then you may want to shorten the time to one minute, or even thirty seconds, so you can get through everything a little faster.

    There’s nothing you really need to track about your two-minute actions. Just do them. If, however, you take an action and don’t finish the project with that one action, you’ll need to clarify what’s next on it, and manage that according to the same criteria.

    If the next action is going to take longer than two minutes, ask yourself, “Am I the best person to be doing it?” If not, hand it off to the appropriate person, in order of priority:

    • Send an e-mail.
    • Write a note or an over-note on paper and route it to that person.
    • Send it a instant message.
    • Add it as an agenda item on a list for your next real-time conversation with that person.
    • Talk with her directly, either face-to-face or by phone.

    When you hand it off to someone else, and if you care at all whether something happens as a result, you’ll need to track it. Depending on how active you need to be it can go to your Waiting list or to your tickler.