Skip to content

Instantly share code, notes, and snippets.

@mottosso
Last active June 5, 2019 18:13
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save mottosso/ccb51050d07a1804d80792149b7c453a to your computer and use it in GitHub Desktop.
Save mottosso/ccb51050d07a1804d80792149b7c453a to your computer and use it in GitHub Desktop.
4th June 2019 - Hello GitHub

Ported this project to GitHub today, and externalised some of the internally developed projects that are capable of standing on their own two feet, to coincide with the existing qjsonmodel.py project I've been using as well, creating a little library of re-usable Qt-components, built on Qt.py.


Introduction

To catch up, I've spent the past 8 weeks working for a client on a project to build a new and improved application launcher, codenamed "launchapp2", to replace their current launcher called "launchapp". Over the coming 9 weeks, this is where I'll document the progress of this application as I bring it to completion.

Sadly, the 8 weeks of documentation is internal to the company and not suitable to publish, but I'll avoid referencing past discoveries and summarise the journey where relevant to ensure this repository of information accurately and completely captures the motivation behind the design decisions made.


Architecture Change

In order to better facilitate a more interactive UI, I've refactored network and file-access away from the controller, and into the model and added a delegate for custom drawing and editing.

Before After
  ______    _________   _____
 |      |  |         | |     |
 | Disk |  | Network | | Rez |
 |______|  |_________| |_____|
    |___       |        __|
   _____|______|_______|____
  |                         |
  |       control.py        |
  |_________________________|
          _|      |__
     ____|____   ____|_____
    |         | |          |
    | view.py | | model.py |
    |_________| |__________|
  ______    _________   _____
 |      |  |         | |     |
 | Disk |  | Network | | Rez |
 |______|  |_________| |_____|
    |___       |        __|
   _____|______|_______|____
  |                         |
  |       model.py          |
  |_________________________|
        |               |
    ____|______         |
   /           \        |
  | delegate.py |       |
   \___________/        |
      |                 |
  ____|____       ______|________
 |         |     |               |
 | view.py |-----| controller.py |
 |_________|     |_______________|

Todo

Here's the current full list of todos that are about to turn into issues.

  1. Override Let the user override a package version with a Beta
  2. App Tab Fix tools-menu
  3. Isolate Tab Ctrl+Click on tab to hide all others
  4. Memcached Tab Inspect the current status of memcached
  5. User Preferences We're going to need a lot of user settings to accommodate for everyone's tastes and optimise everyones workflows.
    1. Allow multiple tabs Let the user decide whether or not to allow more than a single tab be visible at a time. Can help keep clutter down.
    2. Developer Mode Some UI items aren't relevant to the artist, such as picking a version of a given project. Relegate this to a "developer mode", similar to launchapp(1).
    3. Font Size Let the user adjust the global font size with a slider and Ctrl+Plus/Ctrl+Minus keys like in a webbrowser. This ties into the Theming support below.
  6. Save Layout There is a lot of flexibility in layouts, but would be even more useful if one could save a layout and restore it later, and export/import too. Since they're stored as plain-text, it should be relatively straightforward to pull off.
  7. Resolve and Threading At the moment, the GUI locks up on a long resolve. But resolves happen independently of the GUI and can safely happen in the background with a semi-interactive GUI.
  8. Formalise package metadata For _apps and _icons; was thinking of making a .metadata = {} variable in each package with optional data such as these. Don't think there's anything official provided by Rez, but if you know anything let met know!
  9. Copy values from QJsonModel, such as the value of PYTHONPATH. Also copy dict as well, e.g. Copy Value or Copy Dict.
  10. Make list out of PATH-like variables for QJsonModel, so the user can browse those more easily
  11. Visualise Errors Whenever an exception occurs, provide a visual hint that something has gone wrong, with aid towards how to address it.
  12. Variable CSS Inject %(variables)s into CSS so we can change things around, or use SCSS
  13. Dependency Graph Draw packages and their relationships in the launchapp, for debugging and a greater overview of what's happening. Implement this as a widget, so it could potentially also be used standalone, and contributed back to the Rez project (which currently uses an archaic non-interactive method of doing this)
  14. rezconfig Tab Visualise available options of the rezconfig.py, such as package_orderers, package_filter, local_packages_path and rez_packages_path
  15. Packages Tab Improvements
    1. Right-click open path to package for debugging the package.py on disk (if stored on filesystem, could also come from e.g. database)
    2. Disable package, click to temporarily disable the inclusion of a package
    3. Edited indicator, visually indicate whether a package is manually added or edited
    4. Total number of packages, to quickly guage number at a glance
  16. Commands Tab Improvements Add more columns to Commands tab
    1. Running time
    2. Started time
    3. Bring to front
    4. Rename, to manage multiple sessions of the same app, e.g. modeling vs texturing
    5. Color, for user-customisation
  17. Apps Improvements Add columns to Apps
    1. Number of running instances e.g. (2)
    2. Right-click Command-line Let the user launch a command-line from any app (context), for debugging of e.g. PYTHONPATH
  18. Console Improvements
    1. Use QListView instead of QPlainText, for filtering and coloring
    2. Colors in Console for logging levels
    3. Filters in Console for logging levels
  19. Dynamic CSS Monitor CSS file for changes and automatically re-assign it to improve iteration time when working on themes
  20. Themed CSS The above could also be an entrypoint for editing theme colors interactively from within the GUI
  21. Dark theme
  22. Backdrop A larger piece of graphic for a given project. Like a banner of sorts.
  23. Startup animation Keep the user entertained as the initial project is resolved
  24. Focus states Turn focus events into states, for fine grained control over what's available when. E.g. custom buttons when editing environment
  25. Editable Environment Facilitate edits to an alredy resolved environment
  26. Usage tracking To assertain which features are used the most versus least, to focus attention and remove bloat
  27. Japanese Everything is setup to work with translation, just haven't put it in yet.
  28. Resolve Progress Bar A resolve is fast 98% of time time, but when it's not it can help having something to look at and estimate when it will finish
  29. Async Project Listing Whenever a new project is selected, a query is made onto disk which can take 1+ seconds, especially on a remote system.
  30. Taskbar Taskbar icon, with quick way of launching apps. Like current launch app.
  31. List for PATH-like varibales Make PATH variables into lists in QJsonModel
  32. Reload When working on a particular project, e.g. Alita, you may want to reload to the latest one. Currently, you can do that by re-selecting a project, but a reload button is more explicit. It isn't relevant to normal users though, so better put that in developer mode.
  33. Developer Mode setting To hide/unhide various advanced features, such as selecting a version of a project package
  34. Visually highlight edited requirements
  35. Clarify meaning of the icons up-top Via e.g. status-bar help or labels underneath icons
  36. Interactively edit REZ_PACKAGE_PATH Artists should only ever see int, ext and td. And developers should be able to append their own ~/packages path for use during development. And, who knows, maybe there are other paths one would like to add?
  37. Highlight Console on Error State Whenever an error has occurred that could potentially inhibit further use or in any way require an action from the user, visually indicate this by surrounding the Console Tab icon with something very visible, like a red outline. The Console would then also be able to tell the user more about the issue.
  38. Flash Tab Help the user understand when a tab requires attention, primarily the Console which should appear on error.
  39. Color Theme Per Tab Aid the user in understanding which tab is active, by giving each a "theme", like a stripe of color or background.
  40. Interactive Overrides Store user-overrides using the Command-pattern, such that they may be applied (or not) on-demand, visualised interactively and stored on disk for reuse on relaunch.
  41. Persistent console Store contents of console until a certain size or until the user clears it. Load it asynchonously too, to avoid it becoming an influence on startup time.
  42. Spotify-style heads-up message Whenever an error occurs in Spotify, e.g. no connection, no working sound device, the title-bar is enriched with a strongly visible message. We could use that too.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment