mottosso / allzpark Goto Github PK

Hi, @mottosso
Here I list out what I have done and what I have bumped into in my first try out.
Hope you could shed some light :)

Start !

I have created a Python 2.7 environment and did pip install bleeding-rez PySide, with REZ_PACKAGES_PATH set ready.

'PackageFamilyNotFoundError'

When I finally call launchapp2.bat, it raised PackageFamilyNotFoundError.
Then I think, maybe I should prepare some required packages ?

So I take a look at what launchapp2.bat was doing, and I found it was calling rez to step into rez python-2 PySide (I did not set LAUNCHAPP_REQUIRE) these packages (env ?) in order to run launchapp2.

Then I run $ rez-bind --quickstart, for getting those startup packages, and I move those newly generated packages to my _SERVER_PACKAGES path, now I have rez and python-2 packages collected.

Finally, since I already pip installed PySide, I changed LAUNCHAPP_REQUIRE to just rez python-2 and try calling launchapp2.bat again.

PackageRequestError: Not a valid package name: ''

But something is not right ?
I can see the GUI is up, but it shows:

(rez-app) C:\Users\david\Dropbox\github\launchapp2>rez env rez python-2 -- python -m launchapp2 --root %LAUNCHAPP_ROOT% --verbose
==============================
 launchapp2 (1.1.33)
==============================
- Loading Rez..
- Loading Qt..
- Loading launchapp2..
------------------------------
INFO     launchapp2.control Booting..
Resetting..
INFO     launchapp2.control Resetting..
INFO     launchapp2.control Booting..
ERROR    launchapp2.control Could not find projects in C:\Users\david\rez-projects
ERROR    launchapp2.control Couldn't find any projects @ 'C:\Users\david\rez-projects'
INFO     launchapp2.control Ready
INFO     launchapp2.control Loading..
ERROR    launchapp2.control   File "launchapp2\control.py", line 432, in do
    project = self._find_project(project_name, version)
  File "launchapp2\control.py", line 536, in _find_project
    versions = sorted(it, key=lambda x: x.version, reverse=True)
  File "C:\Users\david\rez-app\.rez\packages\rez\2.29.9\platform-windows\arch-AMD64\os-windows-10.0.17134\rez\packages_.py", line 502, in iter_packages
    entries = _get_families(name, paths)
  File "C:\Users\david\rez-app\.rez\packages\rez\2.29.9\platform-windows\arch-AMD64\os-windows-10.0.17134\rez\packages_.py", line 754, in _get_families
    family_resource = repo.get_package_family(name)
  File "C:\Users\david\rez-app\.rez\packages\rez\2.29.9\platform-windows\arch-AMD64\os-windows-10.0.17134\rezplugins\package_repository\filesystem.py", line 491, in get_package_family
    return self.get_family(name)
  File "C:\Users\david\rez-app\.rez\packages\rez\2.29.9\platform-windows\arch-AMD64\os-windows-10.0.17134\rez\backport\lru_cache.py", line 74, in wrapper
    result = user_function(*args, **kwds)
  File "C:\Users\david\rez-app\.rez\packages\rez\2.29.9\platform-windows\arch-AMD64\os-windows-10.0.17134\rezplugins\package_repository\filesystem.py", line 786, in _get_family
    is_valid_package_name(name, raise_error=True)
  File "C:\Users\david\rez-app\.rez\packages\rez\2.29.9\platform-windows\arch-AMD64\os-windows-10.0.17134\rez\utils\formatting.py", line 39, in is_valid_package_name
    raise PackageRequestError("Not a valid package name: %r" % name)

ERROR    launchapp2.control Not a valid package name: ''
Traceback (most recent call last):
  File "launchapp2\control.py", line 432, in do
    project = self._find_project(project_name, version)
  File "launchapp2\control.py", line 536, in _find_project
    versions = sorted(it, key=lambda x: x.version, reverse=True)
  File "C:\Users\david\rez-app\.rez\packages\rez\2.29.9\platform-windows\arch-AMD64\os-windows-10.0.17134\rez\packages_.py", line 502, in iter_packages
    entries = _get_families(name, paths)
  File "C:\Users\david\rez-app\.rez\packages\rez\2.29.9\platform-windows\arch-AMD64\os-windows-10.0.17134\rez\packages_.py", line 754, in _get_families
    family_resource = repo.get_package_family(name)
  File "C:\Users\david\rez-app\.rez\packages\rez\2.29.9\platform-windows\arch-AMD64\os-windows-10.0.17134\rezplugins\package_repository\filesystem.py", line 491, in get_package_family
    return self.get_family(name)
  File "C:\Users\david\rez-app\.rez\packages\rez\2.29.9\platform-windows\arch-AMD64\os-windows-10.0.17134\rez\backport\lru_cache.py", line 74, in wrapper
    result = user_function(*args, **kwds)
  File "C:\Users\david\rez-app\.rez\packages\rez\2.29.9\platform-windows\arch-AMD64\os-windows-10.0.17134\rezplugins\package_repository\filesystem.py", line 786, in _get_family
    is_valid_package_name(name, raise_error=True)
  File "C:\Users\david\rez-app\.rez\packages\rez\2.29.9\platform-windows\arch-AMD64\os-windows-10.0.17134\rez\utils\formatting.py", line 39, in is_valid_package_name
    raise PackageRequestError("Not a valid package name: %r" % name)
rez.exceptions.PackageRequestError: Not a valid package name: ''

Do you have any ideas what's going on ?
And, will there be default (basic/startup) packages shipping with launchapp2 ?

Thanks !

Goal

Reduce the number of steps to switch between projects.

Implementation

With no particular widget in focus, typing should start searching with auto-complete for a matching project.

• ali autocompletes to alita
• a autocompletes to abracadabra
• aa autocompletes to alita (due to the more accurate match, exactly 2 a's and shorter)

Goal

Let the user localise a package using the GUI.

Related

• https://github.com/mottosso/rez-localz

Motivation

Reading packages off of a network share can get slow, especially as the number of packages increase (10-100+) and as each package ships at a significant size (100 mb+).

Implementation

This variable overrides the global rezconfig.py, and may or may not be expected. Find a suitable place in the GUI to let the casual user and developer know that this variable is overriding things, as it may act differently with this set, for otherwise no apparent reason.

Goal

Retain console output between runs.

Motivation

Allspark isn't really an end-all application, it's a mediator to other applications. Therefore, it's expected that it remembers the output from applications that are end-all, like Maya or Visual Studio.

Implementation

Simply store all contents in the console on disk, and enable saving it to a file manually for archival or debugging in an external application like a text editor.

Goal

Establish an iconic look for Allspark.

Motivation

What we've got currently is functional but plain.

Implementation

Draw inspiration from GAEA and Meshroom.

• https://www.youtube.com/watch?v=1A1xXfTlKqM
• https://www.youtube.com/watch?v=v_O6tYKQEBA

Or, from Haiku, where the current icons are coming from.

• https://www.haiku-os.org/slideshows/haiku-1/

Goal

Make the setup process smoother.

Motivation

Getting started currently involves a series of commands in a terminal, creating a number of folders and files for Rez packages, before you can actually start making use of Allspark. What would have been great, was if the GUI could simply be installed via pip install and for it to then guide the user through the remainder of the setup visually. Including creating (and managing) projects.

Implementation

Allspark itself requires Python, Rez and a Qt binding, all of which can happen via pip install allspark. From there, help the user configure a projects directory, creating a new project. Help the user create a new application package and associate it to a project. Next we'll want to install additional software as packages. So help the user package Allspark itself into a package, along with Rez. Then expose pipz and scoopz to install Python libraries and system software. Help the user centralise installed packages and from there, help the user get another user setup on a machine with access to this shared location.

The benefit of making this visual is that we can effectively embed the getting-started-guide into using the GUI, and provide appropriate guidance to the user as it is necessary and respond to whatever is currently happening, like errors or missing steps. An external and static documentation can't compete with that.

It would make adoption that much easier, which in turn would make contributions that much easier and common, making life greater for everyone.

At the moment, "default" means "whatever the value was on startup". Which seems allright, however when combined with the GUI also storing values between restarts, a non-default value will appear as default is saved with the GUI on close and reopened. That's a bug.

Goal

Make the console more useful.

Motivation

Currently a plain-text field which is great for copy-pasting, but not much else.

Implementation

1. Use QListView instead of QPlainText, for filtering and coloring
2. Colors in Console for logging levels
3. Filters in Console for logging levels

This will enable filtering, collapsing and metadata per line (such as a stack trace hidden in a popup on hover for a single line), condensing important material and enabling greater amounts of logging to take place. Copy/pasting could happen per-line, as opposed to per-character.

Goal

Help the user find more elaborate documentation for Allspark.

Implementation

Upon clicking on the Allspark logo to the right of the GUI, take them to a pre-determined URL, configurable via the environment.

$env:ALLSPARK_HELP_URL = "https://allspark.sh"

Goal

Make each project unique.

Motivation

Working on a project for month or years on end can be draining, so it's important to keep the software interesting. It also helps the user quickly grok that he's in the right project, if he could see some relevant graphic or coloration to confirm his choice.

Implementation

• Let the project define a theme, either as part of its payload or as a selection of available ones.
• Let the project provide a "backdrop", something to appear in the header of the application, a plain image of pre-defined size (e.g. 800x400)

Goal

Make it even easier to transition to and from the command-line.

Related

• https://news.ycombinator.com/item?id=20388185#unv_20393615

Motivation

The full command-line statement is currently made available from an executed command in the Commands tab.

But it could be more prominent, and available before a command is actually launched. Something increasingly important when the command is heavy, like Autodesk Maya.

Implementation

Augment/Replace the status bar with a "command bar", something easily copyable. Also investigate whether you can paste a command, and configure the GUI accordingly. E.g. pasting project A with application B and tool C could activate the corresponding project, select the app and tool in the GUI. Something increasingly important as the command-line arguments start to add up.

Goal

Help the user understand the differences between tabs.

Motivation

In SideFx Houdini, there's this neat feature of coloring the tab based on what "type" it is. E.g. the flowchart tab could be blue, Details View could be red and so forth. It's a subtle way of calling attention to type, without using words or images. With many tabs open, it can help guide the eye to the right one, without having to read the title of each one.

Implementation

It's degraded throughout the years and isn't the best example, but here's what it looks like in Houdini 16.

We can do better than that!

Goal

Allow the user to browse through documentation at various points in history.

Motivation

Currently, documentation is singular. When there is a change, anything referring to a previous address breaks. What's worse, documenting the progress of making documentation is not feasible, as development inherently changes it. So there's no way to reference, say, the initial release of the website, as it was at the beginning.

Git and GitHub is great at this; you can create a "permalink" to any line of code, that is guaranteed to never break. The link references not only a given line in a given file, but at a given time. Documentation should work like that too.

Implementation

Replace the gh-deploy script with one that does the following.

1. Build the documentation
2. Switch to gh-pages branch
3. Copy documentation into repo folder, replace anything already there. (Nothing is deleted)
4. Make a second copy under c/<sha>/ where sha is the commit it from which the documentation was built, first deleting the directory if already exists
5. Push

The result is an overwrite of existing documentation, guaranteeing that nothing old remains by simply overwriting mkdocs.yml; any old pages or images won't get referenced and thus won't interfere. Over time, the c/ directory grows for every build of a new commit made. Because versions are stored per commit, several builds can safely be made from the same commit without incurring unnecessary disk space.

Over time, if each build is 1-2 mb (images referenced from GitHub externally), the gh-pages branch can grow rather large. But that's fine, because it's hosted on GitHub where storage and bandwidth is effectively free.

Goal

Help the package author (and user) understand why packages were chosen.

Motivation

There's already a tool for this.

rez env python-2 pyside -- rez gui

But it isn't working out-of-the-box and there are no documentation on how to get it to work. Some deep diving revealed that it's not the Rez GUI having trouble, and it's not the Rez utils that it calls, but rather pydot itself which is the underlying library being used.

And that's all information it gives us. Not very useful!

Implementation

Have a look at any available Python node interface, and integrate this here.

Goal

Enhance the project selection experience, and facilitate additional "layers" of projects.

Motivation

Projects are rather boring looking right now, and wouldn't scale to also selecting packages for assets or shots.

Implementation

Currently, the command-line equivalent of a command executed via the GUI is hand-crafted, and doesn't stay up to date with changes or addition to the interface (e.g. #41). We need a more automatic means of generating this command.

1. Either investigate whether Rez itself is able (or can be made) to output the command-line version of a ResolvedContext.execute_shell
2. Implement a double-dispatch or command-pattern approach to calling on Rez, such that we can intercept it and generate the command-line version from the same inputs as Rez is seeing.
3. Possibly there are more options.

Currently, the pre-selected application project is determined by the one last used, regardless of project. But sometimes, what you want is to keep working in the same application across multiple projects. Therefore, the startup application should be stored alongside a given project, rather than with Allspark as a whole.

I Mottosso,
This looks great I just wanted to know the current status of the project?
From the issues, it seems there are only cosmetic issues left?

Thanks for making bleeding-rez 🙏

Goal

Let the user manage multiple layouts

Motivation

User interface elements can be moved around, docked and detached, but not saved. A user may want one layout for debugging, and another for plain usage of the application.

Implementation

Add a little dropdown, similar to Maya, that lets the artist switch between saved layouts.

Goal

Add at least one additional theme, a dark one.

Motivation

The most requested feature has been the ability to change the theme. Possibly because it's the first thing you see as you enter the app and therefore the thing that sticks with you during your journey.

Implementation

Use the #13 to craft a dark theme, save it to file and offer it as an option in the Preferences Tab.

Allzpark (a.k.a. LaunchApp2) started as a 4-month commission for the Japanese Studio Anima. Time was divided into roughly these parts.

1. Week 0-0 Tour of physical building, infrastructure and crew
2. Week 1-2 Requirements gathering, an evaluation if current system
3. Week 3-4 Evaluation of off-the-shelf options, e.g. Rez
4. Week 5-6 Evaluation of studio, system and personnel resources
5. Week 7-8 Integration and testing of fundamental infrastucture software, Ansible
6. Week 9-10 Research and development of Rez to fit the criteria and initial prototype
7. Week 11-12 Conversion of existing package repository
8. Week 13-14 Implementation of graphical user interface, LaunchApp2
9. Week 15-16 Refinement of features, including localisation
10. Week 17-18 Final integration and training of staff

Journal

Allzpark was initially an internal project, never intended to be open sourced. As a result, the first 2 months of development are locked away behind an internal journal for the company (due to disclosure of sensitive information).

Luckily, it was around this time that Allzpark got approved for open source and when I was able to start sharing its development publicly, so that you are able to take part in the design decisions made, the why and how. This way, you're able to accurately determine whether a solution to a new problem takes the original requirements into consideration; something all too often lost in software projects.

Find below the daily journal from this development since then.

• 4th June 2019 - Hello GitHub
• 5th June 2019 - Ticking boxes
• 6th June 2019 - Ticking boxes pt. 2
• 7th June 2019 - Software Packaging Detour
• 10th June 2019 - Software Packaging Detour pt. 2
• 11th June 2019 - Ticking Boxes pt. 3
• 12th June 2019 - Ticking Boxes pt. 4
• 13th June 2019 - Filtering and Commands
• 17th June 2019 - Project Packages
• 18th June 2019 - Performance
• 21st June 2019 - Linux
• 24th June 2019 - Localisation pt. 1
• 25th June 2019 - Localisation pt. 2
• 26th June 2019 - Localisation pt. 3
• 27nd June 2019 - Tutorials
• 28th June 2018 - Localisation pt. 4
• 1st July 2019 - Website
• 2nd July 2019 - Website pt. 2
• 3rd July 2019 - Website pt. 3
• 5th July 2019 - Website pt. 4
• 8th July 2019 - Stability
• 9th July 2019 - Project Selector

Goal

Widen the scope of our documentation.

Motivation

All shell commands are currently written in PowerShell, which is unlikely to fit everyone. cmd and bash are also options, and should be represented as well.

Implementation

The native approach would be at to write every example 3 times, once for each shell language. But that would make 2 thirds of all commands superfluous to the reader, and more once we implement support for more languages.

So instead, write every example 3 times, and let the user pick which one to view. Like Avalon does.

Goal

Let the user make his own themes, interactively.

Motivation

Qt makes this really easy, so why not.

Implementation

Add a text-field in a tab that when edited trigger an update to setStyleSheet of the application.

This should override any prior CSS and let the user change anything the developer is able to.

• Edit CSS interactively
• Save CSS in a "Theme", that can be loaded from disk
• Swap between before/after interactively

Goal

Enable switching projects without using a mouse.

Motivation

Ultimately, Allzpark is a GUI for a command-line tool, and preferably you'd navigate using your keyboard in the GUI as you would on the command-line. No mouse needed.

Implementation

I found this recently which had a neat idea for enabling search via hotkey.

• https://www.mankier.com/1/cargo-install

Pressing the "s" key made the search field gain focus for subsequent typing, which in turn triggered a search.

Goal

Enhance engagement, facilitate return visits.

Motivation

Forums and chat's are interesting because they not only show you the latest changes, but they can also notify you (if you want) when there's something new to read.

Documentation doesn't do that, not even if what is being updated is interesting or even important to you.

Implementation

Add a "Latest" page to the docs, with a summary of most recent changes, listed in chronological order. This should help encourage revisits and staying on top of when something you're interested in has changed.

Also add a little time icon to pages, to view their commit history.

Goal

Improve the localisation experience.

• Part 1

Implementation

Let the current implementation simmer for a bit, and gather user experience reports for a round 2.

Goal

Account for #18 in CSS.

Motivation

CSS currently works in pixel-dimensions, which doesn't bode well for HDPi screens.

Implementation

Multiple anything suffixed with px in CSS by a scale value, as per #18.

Add an icon and label from project package, in the project selector, #31.

Goal

Make landing page 120% appealing relative what it is.

Motivation

I stumbled upon this (unrelated) website and really liked it.

• https://bvckup2.com/

Goal

Avoid copyright issues, enhance searchability and reduce domain cost.

Motivation

I really like the name Allspark, as it references my favourite movie of all time, the 2007 version of Transformers. But it is an IP and although I doubt anyone would come after an open source project nor that it has any effect on their bottom line, it does make the project that much more difficult to search for and the domain name is obviously swamped and easily mistyped (for some toy shop or VFX production house, for example)

Implementation

I'm considering either Allsparkz to align with the related rez-pipz, scoopz, localz projects etc. Or Allzpark. The Z making it "Rezzified".

Goal

Consolidate configuration into a single file, and extend the kind of customisation made possible.

Motivation

Projects are currently specified via the command-line.

$ rez env allspark -- allspark --root c:\my\projects

Or environment variable.

$env:ALLSPARK_PROJECTS="c:\my\projects"
rez env allspark -- allspark

But arguments must be remembered, and environment variables must either be set globally or prior to launching a console. What would have been nice is, like Rez, have a written configuration file used during startup, that could be controlled external from launching.

Additionally, we'll want to enable control over more finely grained aspects, such as how projects are discovered. Currently, that happens via os.listdir of a given absolute path. But what if projects aren't on disk? What if they're in Mongo or a third-party provider like ftrack or shotgun?

Implementation

Implement a allsparkconfig.py capable of hosting not only attributes like projects_dir and applciations_dir but also project_discovery_function taking a callable returning a list of projects, in whatever means make sense.

allsparkconfig.py

projects_dir = r"c:\packages\proj"
applications_dir = r"c:\packages\apps"  # (optional)

def project_discovery_function():
  """Called when looking for projects"""
  import os
  return os.listdir(projects_dir)

Currently, the filter (such as *.beta), development and localized statuses are only for packages resolved from the project/application combination. But they should apply to project and application as well.

Goal

Expose the --no-local argument of rez env to Allspark.

Motivation

Sometimes, as a developer, you just want to run an application in an identical context to your artists. At the moment, you can do that if you move or delete your development packages. But that's a lot to ask. Rez deals with this via the --no-local flag, which temporarily switches off your local development repository.

Implementation

Add a toggle of sorts, somewhere convenient to developers, and not necessarily up-front and center for artists to use or accidentally press.

Goal

Quickly make edits to an environment, post-resolve.

Motivation

During development, it can be useful to edit an environment, prior to running it.

It would be the graphical equivalent to doing..

$ rez env alita maya
> $ set MYCUSTOMVARIABLE=True
> $ maya

Where the set command is run inbetween resolving and running Maya.

Implementation

The GUI currently displays the future environment of an application/project. Let the user double-click to edit any of those.

Goal

Enable use of --patch from within the GUI.

Motivation

Picture working on a new package for a project. You'd want to test this project out within the context of a real project, so that once you make it a requirement of said project you'd know what to expect.

Currently, the only way to accomplish this is to launch a command-line from within a project/application context, and call rez env my_new_package --patch followed by launching the application from there.

Implementation

Add a freeform text field to the Packages tab.

Goal

Enable deep introspection of packages, and encourage more metadata and docs being added to each package.

Motivation

Packages contain useful information, such as who made it and when, comments for a given version along with potential for graphics and additional GUI-only metadata. Currently there are no means of actually making use of that data, other than label and icon from the list-view itself.

Implementation

When a package has been selected, swap out the applications view for an "info view", with all information about a package laid out nicely.

Goal

Enable customisation of how metadata is gathered from a given package.

Motivation

Metadata is currently presumed to exist within a package as a _data dictionary variable.

name = "maya"
version = "2018"
_data = {
  "label": "Autodesk Maya",
  "icon": "maya_{width}_{height}"
}

There are a few issues with that.

1. We can't assume _data is free for us to claim; the user may already be using it for something else.
2. We can't assume metadata is present in the package itself, or even package.py. It may come from a side-car file or database, in which case the package may be be used as merely an indicator of where to find it (e.g. by name/version combination)
3. We can't assume all metadata is equal. For example, project metadata like icon and backdrop may come from a database, whereas the icon for Maya may reside in the package.

Implementation

Expose the current reader to allzparkconfig.py.

def package_metadata_reader(package):
  return {
    "label": package._data["label"],
    "icon": database.query({"key": package.name, "value": "icon"})
  }

To facilitate lengthy queries, make the call asynchronous from within Allzpark.

Goal

Launch apps more quickly, and without a window

Motivation

The Allspark window is great, but sometimes the information it provides isn't necessary or useful. Sometimes you just want another instance of Maya up and running, no fuss.

Implementation

Add a taskbar icon that, once clicked, reveals a list of applications to run.

Goal

Improve interactivity.

Motivation

Resolving contexts is typically fast, less than 200 ms. But sometimes there is a cache-miss at which point resolving can take up to 10 seconds. It's during that time that it would appear as though the GUI has stopped doing anything (it remains responsive thanks to its async nature, but appears to be working on empty).

Implementation

Rez doesn't tell you about how far it's gotten, but somewhere in there there is a resolving algorithm running a series of steps. It would be great if we could gain insight into this process, even if it only told you "Processing iteration 5".. "6".. "7".. and so forth, as it gives the user an idea of what's going on. Best case, it would say "5/9", "6/9" and so forth, such that we could derive a percentage out of it.

Goal

Improve visibility of Rez settings

Motivation

For developers and package authors, something to gain insight into a potentially huge configuration.

Implementation

Visualise available options of the rezconfig.py, such as package_orderers, package_filter, local_packages_path and rez_packages_path from the (many) rezconfig.py, along with which file they were defined in.

Sometimes, on exit, Allzpark pauses for a second whilst Windows Error Reporting tool gets busy in the background. Shortly thereafter, it silently closes.

• Windows 10
• Python-3.7 x64
• PySide2-5.12

This is the result of a segmentation error or similar, something possibly caused by a bad signal connection or memory leak somewhere. Something that isn't able to clean up after itself. It isn't critical and doesn't appear to have any side-effects other than causing this occasional slowdown on exit, but I'm unsure of how it manifests itself on other platforms. Logging it here for future reference.

Goal

Help the reader understand what they're getting themselves into.

Motivation

Some pages or sections are bound to be long, but some are short.

Implementation

Add a quick overview of page or section length, visible on hover.

Containing:

1. Word count (e.g. ~35,000 characters)
2. Approximate read time (e.g. "10 mins")
3. Icon, something nice

launchapp2 is an internal name, following another internal app called launchapp. We need a better name.

allspark

AllSpark is an ancient artifact or object capable of creating new Transformer life by bestowing machinery with sparks. - Wiki

Goal

Projects in Allzpark are versioned like any other software, and sometimes you'll want to revert to a previous (or later, beta) version.

Implementation

There's already a toggle for this, it just doesn't work.

Goal

Make Allspark usable on scaled displays.

Motivation

With a retina/4K screen, Windows and other operating systems provides a global scale to account for the otherwise tiny text and user interfaces. Each application must account for this in its design, which is why we're using px(int) for any of our pixel-based sizes; to scale them. However this isn't implemented yet and Allspark likely wouldn't look very nice when scaled.

Implementation

Take scale into account, Qt provides utilities for this. Alternatively, use the global environment variable to globally scale everything under the hood; it's possible this may work as Allspark is a standalone application (as opposed to something running in e.g. Maya).

Goal

Help the user understand when Allspark needs his help.

Motivation

Spotify has a nice method of visualising errors.

It's front and center, which is just right considering it's the thing requiring immediate attention.

Goal

Enable customisation of how applications are associated to a project.

Motivation

Applications relative a given project are currently coming from the project package's requires = [] list, filtering any requirement that is "~weak". That should cover common cases, but there may be times where additional customisation or filtering is necessary.

Implementation

Expose find_applications(package) to allzparkconfig.py

def find_applications(package):
  return list(a for a in package.requires if a.weak)

Goal

Keep the user and developer up to date on memcached status.

Motivation

Memcached is responsible for the performance of Allspark and Rez, and can be inspected via the command-line.

rez memcache
CACHE SERVER          UPTIME  HITS  MISSES  HIT RATIO  MEMORY  USED
------------          ------  ----  ------  ---------  ------  ----
192.168.178.97:11211  3 days  1471  298     83%        64 Mb   447 Kb (0%)

Let's make this possible via the GUI as well.

Implementation

Add a tab for memcached, or as part of the Preferences Tab.

It isn't clear whether the project and version labels are selectable, until you hover over them. Better add something to clarify that, like the arrow you'd find on a QComboBox.

But, rather than shipping a png of an arrow, generate one via QPainter such that we can style it and support user-customisable theming.