Skip to content

Instantly share code, notes, and snippets.

@mottosso
Created July 10, 2019 15:07
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/f92a43a304dfe6b7b51ff9127d2450bd to your computer and use it in GitHub Desktop.
Save mottosso/f92a43a304dfe6b7b51ff9127d2450bd to your computer and use it in GitHub Desktop.
10th July 2019 - Version Picker

Today I had a look at the version picked, some cpsmetics with regards to the project package and exposing things to allzpackconfig.py.


Completer

Many subtleties when it comes to completion, the question is what to consider start and end of a session? I'm testing with focus event.

  1. On focus, session starts (e.g. via click or tab)
    • Current value is stored
  2. On focus lost
    • Session end
  3. On session end:
    • Complete current value
    • If found: emit changed()
    • If not: restore_cached()

Does this cover all usecases? Sounds like it, but no; focus is split between QLineEdit and the associated QCompleter dialog, and you wouldn't want completion to finish if you move from text to the list of completions or vice versa. We also can't listen for the QCompleter.activated signal, because it is emitted separately from losing focus which means we'll trigger a change twice.

1h later

On top of that, another hour was spent with what appears to be a two Qt bugs working in tandhem.

  1. The QCompleter.activated is emitted only sometimes
  2. The QCompleter.setCompletionPrefix isn't called on user picking an item

The result of (2) is that we can type and hit enter, completion picks up on what you're typed. But if a user picks an item in the list, it'll sometimes take your pick into consideration, but other times does not. Because it happens only sometimes, it's really difficult to debug or reproduce..

What I ended up doing was reduce the possible sessions to the user finishing an edit in the QLineEdit. That means either hitting enter or it losing focus; the benefit is that we aren't having to think about how that happens, that's a native signal to the QLineEdit (which seems more thought through than the QCompleter overall) and hasn't broken so far.

All good then? Almost, it does mean the user can't simply select a project from the list and have it activated, but must follow up with Enter or lost focus. Will return to this once we've had some experience with the mechanism.


Version Pick

With that out of the way, we can reuse our work on picking a project version.


Broken Packages

I've made it so that projects appear even when they don't have a package. I found this helps during development, as a package may not yet exist once you start authoring things. And if a network drive or the like is down, you'd still want some indication that a project is there, but just doesn't work right not.

The same applies to projects, applications and packages. If they don't exist or resolve properly, they still appear in the GUI, just can't be edited or used.


Configuration

I've added metadata_from_package and applications_from_package to the allzparkconfig.py.


Project Metadata

With the above additions, I've exposed project label and icon from its package metadata.

package.py

name = "alita"
_data = {
    "label": "Alita - Battle Angel",
    "icon": "{root}/resources/icon_{width}x{height}.png"
}

Which looks something like this.

allzpark_projecticon


Tomorrow

There are a few kinks left to iron out with the QCompleter - the selection sometimes remains behind, even after focus is lost. But I'll leave cosmetics for now, it's in a relatively good state, and move onto localisation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment