mottosso / allzpark Goto Github PK
View Code? Open in Web Editor NEWPackage-based application launcher for VFX and games production
Home Page: https://allzpark.com
License: GNU Lesser General Public License v3.0
Package-based application launcher for VFX and games production
Home Page: https://allzpark.com
License: GNU Lesser General Public License v3.0
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 :)
I have created a Python 2.7 environment and did pip install bleeding-rez PySide
, with REZ_PACKAGES_PATH
set ready.
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.
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 !
Reduce the number of steps to switch between projects.
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)Let the user localise a package using the GUI.
Related
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+).
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.
Retain console output between runs.
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.
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.
Make the setup process smoother.
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.
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.
Make the console more useful.
Currently a plain-text field which is great for copy-pasting, but not much else.
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.
Help the user find more elaborate documentation for Allspark.
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"
Make each project unique.
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.
Make it even easier to transition to and from the command-line.
Related
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.
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.
Help the user understand the differences between tabs.
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.
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!
Allow the user to browse through documentation at various points in history.
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.
Replace the gh-deploy
script with one that does the following.
gh-pages
branchc/<sha>/
where sha
is the commit it from which the documentation was built, first deleting the directory if already existsThe 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.
Help the package author (and user) understand why packages were chosen.
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!
Have a look at any available Python node interface, and integrate this here.
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.
ResolvedContext.execute_shell
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
๐
Let the user manage multiple layouts
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.
Add a little dropdown, similar to Maya, that lets the artist switch between saved layouts.
Add at least one additional theme, a dark one.
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.
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.
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.
Widen the scope of our documentation.
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.
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.
Let the user make his own themes, interactively.
Qt makes this really easy, so why not.
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.
Enable switching projects without using a mouse.
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.
I found this recently which had a neat idea for enabling search via hotkey.
Pressing the "s" key made the search field gain focus for subsequent typing, which in turn triggered a search.
Enhance engagement, facilitate return visits.
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.
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.
Improve the localisation experience.
Let the current implementation simmer for a bit, and gather user experience reports for a round 2.
Add an icon and label from project package, in the project selector, #31.
Make landing page 120% appealing relative what it is.
I stumbled upon this (unrelated) website and really liked it.
Avoid copyright issues, enhance searchability and reduce domain cost.
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)
I'm considering either Allsparkz to align with the related rez-pipz, scoopz, localz projects etc. Or Allzpark. The Z making it "Rezzified".
Consolidate configuration into a single file, and extend the kind of customisation made possible.
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?
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.
Expose the --no-local
argument of rez env
to Allspark.
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.
Add a toggle of sorts, somewhere convenient to developers, and not necessarily up-front and center for artists to use or accidentally press.
Quickly make edits to an environment, post-resolve.
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.
The GUI currently displays the future environment of an application/project. Let the user double-click to edit any of those.
Enable use of --patch
from within the GUI.
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.
Add a freeform text field to the Packages tab.
Enable deep introspection of packages, and encourage more metadata and docs being added to each package.
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.
When a package has been selected, swap out the applications view for an "info view", with all information about a package laid out nicely.
Enable customisation of how metadata is gathered from a given package.
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.
_data
is free for us to claim; the user may already be using it for something else.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)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.
Launch apps more quickly, and without a window
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.
Add a taskbar icon that, once clicked, reveals a list of applications to run.
Improve interactivity.
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).
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.
Improve visibility of Rez settings
For developers and package authors, something to gain insight into a potentially huge configuration.
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.
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.
Help the reader understand what they're getting themselves into.
Some pages or sections are bound to be long, but some are short.
Add a quick overview of page or section length, visible on hover.
Containing:
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
Make Allspark usable on scaled displays.
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.
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).
Enable customisation of how applications are associated to a project.
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.
Expose find_applications(package)
to allzparkconfig.py
def find_applications(package):
return list(a for a in package.requires if a.weak)
Keep the user and developer up to date on memcached status.
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.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.