TODO.txt

Multi-root and multi-home
=========================


~ multiple caches for different machines:
    √ one is flagged as the one for writing, and the rest are for reading
    √ .sgfs/cache/master.sqlite (default) and mikeb.sqlite
    - explicitly test multiple
    - test when one of them is bad

- Tagging primary vs. artifacts:

    Idea 1: multiple named roots that entities may be tagged in each
        - sgfs.path_for_entity(entity, root='artifacts')
        - have an SGFS cache in each project root

    Idea 2: Arbitrary "tag_type" / "context" / "namespace" on each tag.
        - May have same project tagged with different context, which
          would result in a path cache there. Projects would need to be
          discoverable via SGFS_ROOT="/path1:/path2" or a per-project
          mechanism (e.g. SGFS_PROJECT_52=/path1:/path2)
        - Would allow for multiple paths for a single entity in the same
          project beside themselves.
        - Only allow tags within already tagged locations. The current
          practise of absolute paths would be discouraged.
        - "path" in tags should be relative to the containing project. Should
          repair all existing tags. This would only be a problem for the
          Project which would then be allowed to move.

- Support projects in different locations on different machines.

    Idea 1: For each root, could be provided a set of potential locations.
        - One, and only one, must exist on the local machine and be tagged such.
        - sgfs.localize(path) could translate it the local version.
        - sgfs.localize(path, context='markmedia') could translate to
          the specific one.

    Idea 2: Largely the same, except the locations are named.
        - The current location must be named, or assumed "primary".

- multiple roots on different machines:

    - both SGFS_ROOT (which is assumed to contain projects) but also pre-project
    - so, multiple sets of dirmap: one global and one per-project

    - sgfs.localize('/Volumes/CGroot/Projects/SitG')
      -> '/Volumes/heap/sitg/work/film'
    - sgfs.localize('/Volumes/CGroot/Projects/Sandbox')
      -> '/Users/mikeboers/Documents/MarkMedia/Projects/Sandbox'


- per-host config (via SGFS_CONFIG or entry_points)
- per-project config (via .sgfs/config.py or entry_points)

- rename some functions
    - SGFS.entities_{above,at,below}_path




Remote
======

- PostgreSQL based PathCache
- projects still need to be identifiable
    - option 1. could just tag them on every machine
    - option 2. PathCache can identify project roots
      PathCache.iter_project_roots
    - option 3. override with envvars: SGFS_PROJECT_65_ROOT

- since data is stored in tag files, which can easily not be transfered to
  remote, it is interesting to consider moving that data into the cache as
  well, just as a backup. If they both contain a last_updated date or event_id
  then it is easy enough to reconcile them


Picker
=======

- Rename module:
    - sgfs.model_view (perhaps too generic)
    - sgfs.entity_picker
    - sgfs.state_picker (this is how it is implemented)

- Preview not hidden on Maya 2011.

- Filesystem nodes.

- Sort order or sort-key that is seperate from the display data
- Auto-select, to automatically jump to the latest version. Takes effect
  when a node is added, has "select" in `view_data`, and its parent is
  already selected

- Node to wrap around other nodes to get a union of them. Then we can
  easily add a union of PublishEvent and WorkFiles

- unit tests for columnview


- refactoring plan

  - uitools.dictmodel.DictModel
    - DictNode handles all of the data/flags/index/parent/whatever
      that the model normally does, and it is represented by a dictionary
      mapping Qt.ItemDataRole (or their uitools.qt.roles version) to a
      value

  - uitools.statemodel.StateModel
    - extends DictModel to have "generators" which "mount" onto the current
      state and provide children
    - class StateNode(DictNode): pass

  - uitools.headeredlistview.HeaderedListView
    - what I wrote this morning

  - uitools.headeredcolumnview.HeaderedColumnView
    - the bulk of the SGFS picker view

  - generators are classes

    - Generator.mount(self, state):
      return self if it does mount here

    - Generator.generate(self, state, schedule_async):
      returns an iterator of nodes (or node tuples), and may schedule async
      node-fetching-functions via passed function. If None is returned and
      nothing is scheduled, then it does not mount here and there are no
      children.

    - Generator.regenerate(self, state):
      return immediate children that appear to exist in the given state

  - GeneratedNode is created from the results, holding a reference to
    its Generator (for resetting, etc). This inherits from the StateNode

  - the plan (that should be incremental)
    √ HeaderedListView into uitools
      √ uitools.roles.get_role_for_name('header')
    √ use HeaderedListView in picker ColumnView:
      √ pull headers from the nodes
      √ restore resizing
      - loading/error/counts in headers?
        - empty headers can be emitted via first fetch_children, and then
          they can be removed via an updated view_data. Perhaps including
          {'ignore': True} would cause it to not be rendered any more.


- document how to create new picker nodes, and how the ``state`` works.
  - ``self`` as the last entity is deprecated; use ``last_entity`` or
    ``entities`` (a tuple of them in order) from here forward.
- refactor picker names to be camelCase
- add path for all entities?
  - Can we trust that a ``path`` is always the last path, or do we need to
    check the state deltas to be sure? Refactoring state into new_state and
    all_state would be a good idea, or if state was actually a dictionary
    stack, where state.last['path'] would get you the deltas

- refactor so that the nodes that the model uses (e.g. group, leaf, general
  data and flags) are different from the ones that generate that data

  - the model delegates all rowCount, columnCount, data, flags, etc to the
    ModelNode attached to the ModelIndex. Perhaps refactor this model into
    something in uitools.model_graph that we can use for more things.

  - somehow, multiple generators should be able to mount to a state and
    generate children.
    - sorting is done on the entire list by the model via a "sort_key" in the
      view_data.
    - Where do headers come from? If there is only one header, then it is
      tricky since there are several sources to pick from. If you can have
      multiple headers (like ActionMenuItems) then it is no longer a problem.

  - simpler signal that a generator cannot mount on the state; current
    raising of TypeError is overloading that exception type.




  - if headers are set by an item in that section, then the header logic (from
    the generators point of view) will get easier. What do we set the header to
    for a section that does not have children? "Empty"?

    - sometimes we want the header to come from the parent node: the Shotgun
      ones set the header to the entity_type
    - sometimes we want the header to come from the node itself

  - if headers are created in a similar manner to the Shotgun action menu (in
    which headers are in the flow of the items and group several items together)
    then there are some more possibilities. Would want to pin a header to the
    top and then have some more going down.

  - move the key/uuid into the view_data instead of being a seperate object?


- prioritize the threads that you just clicked on
    - this may require me to write my own threadpool around queue.LifoQueue
    - since we dont take the results from the futures, they could be more
      general and pop the node with the most recent access time from the queue
    - use shotgun batch mode to jam a bunch of the queued requests together




- SGFSChildren to grab children

- be able to specify text that it can match when you type

- ComboBoxView
      
- thumbnails from shotgun
    'thumbnail' displaymode, or with a delegate



Create Structure
=================

- Set better permissions, including owner/group/perms from config.
    - Sticky bit on directory will go a long way in our setup.
    - Don't be recursive about the configuration; everything that isn't default
      permissions should be set explicitly.


Templates
=========

- Patterns in template names to allow for maya_*_publish template.

- Template mini-language:
  Standard formatting:
      {version:04d}
  Expressions (like Jinja):
      {{ '%04d' % version }}
      {{ '{{' }} for raw {{
  Conditions (like Jinja):
      {% if <test> %}
      {% for i in range(10) -%}
          {{ ', ' if i else '' }}{{ i }}
      {%- endfor %}
  Flags (signals to compiler):
      {# collapse_path(True) #}
    


Work Namer (aka SceneName)
==========================

- sgfs.scene_name warnings should collect in a list and be displayed to
  the user by the UI, optionally.


Work Picker (aka product_select)
================================

- Should this be changed to the sgfs.state_picker?

SceneName
---------

- can this be done with templates? Seems like it can IFF we can either use
  regexes (or something like them) or have multiple templates
    
    maya_work_area: maya/scenes
    
    maya_scene_name:
        - v{version}/revisions/{Task[entity][code]}_{Task[step][short_name]}_{detail}_v{version:04d}_r{revision:04d}{ext}
        - v{version}/{Task[entity][code]}_{Task[step][short_name]}_{detail}_v{version:04d}{ext}
    
    maya_scene_name:
        - {Task[entity][code]}_{Task[step][short_name]}_{detail}_v{version:04d}_r{revision:04d}{ext}
        - {Task[entity][code]}_{Task[step][short_name]}_{detail}_v{version:04d}{ext}
        
- set_workspace()
- set_filename(filename, strict=False)
- more portable warnings and errors
- SceneNameWidget
- expose the underlying SceneName (but leave a copy where it was for b/c)


Other
=====

- sgfs-tag --list [path]
  sgfs-tag --create type id [path]
  sgfs-tag --delete [[type] id] [path]

- refactor relinking commands onto the path cache since it is so low level

- document sgfs troubleshooting:
    Q: I just started a new project but cannot create folders!
    Q: I created folders, then changed something about the entity, but it
       does not create new folders for it!

- sgfs.template can be given default data that must match, so it builds a new
  regex for it and thus can be more accurate in spotting other values

- SGFS(magic) pull it from magic.session if isinstance(magic, Entity)

- sgfs tag deserializing needs to be able to return as much as possible even
  if classes/functions are not availible

- sgpublish.ui.exporter.basic.Dialog
    - just takes an exporter, and has no extra controls

- How to deal with accidentally relinking a folder that was copied by an artist
  as a template? If the copy comes after alphabetically then it results in
  the SGFS cache mapping to the copy.

- get scene_name working off of sgfs publishes, then there is nothing
  stopping us from migrating the geocacher to mayatools

- Refactor scene_name so that it can have parts of it set relatively
  easily
    - call it sgfs.work_area, and LEAVE THE OLD ONE so that I break less things
    - perhaps work with SGFS templates?
    - "Options" toggle to hide the sub-directory
    - I haven't ever seen people set the entity or step, so push them into
      the hidden settings

- Rename a few things: scene_name and product_select:
    - both of these things work with arbitrary "products", which are files
      that are associated with Shotgun Tasks:
        - sgfs.product_name.ProductName
        - sgfs.product_selector.ProductSelectorLayout
    - products are things that are the results of work, so maybe workfile:
        - sgfs.workfile_name or work_name or work_namer
        - sgfs.workfile_pick or work_pick or work_picker
        - sgfs.path_picker (this is how it is implemented)

- Cache lookups by code/name as well as by ID.
- Get setup.py including the schema (via a MANIFEST?).
- Rename some SGFS methods:
    Clumsy or too explicit:
        - get_directory_entity_tags
        - tag_directory_with_entity
    Unify:
        - path_for_entity
            BUT, this is the path for the specific given entity, where the
            "from"s' products derive from that path. This is a 1-to-1
            relationship.
        - entities_from_path
            BUT, "from_path" implies the products are derived from the path, not
            from the contents of the directory at that path
        - context_from_path
            BUT, same as entities_from_path
        - entities_in_directory (recursive version of above)
            BUT, "in" implies we are travelling deeper into a diretory, while
            the others travel up the heirarchy.
        - context_from_entities
            This may be the only legitimate one. Perhaps context_for_entities,
            BUT this is also a derived product.