Coming to Grips with QML

Working on a new project where things are just outside your comfort zone is exciting, but it’s also risky. The drive to make progress can tempt you to skip important details.

I underestimated how different QML was from classic QtWidgets and started to hit hurdles, taking a step back to learn QML with intention is how I’m moving forward anew.

Learning QtQuick

Since I have experience working with Qt Widgets, I started using QtQuick in the same way. Creating a widget (AKA component) in Qt Design Studio, and drop it into the main Python code to display it.

While that sort of works - you can see at least some of the widgets, the way you interact with and change things like text fields is fundamentally different. For a functional interface I needed to take a step back and learn QML/QtQuick from the ground up.

I’ve now completed several courses through Qt Academy, and have a better grasp on how QML works. But there are still a couple of big things that I need to investigate.

• I want to keep the UI layout code cleanly separated from scripting. So I need to understand how .ui.qml and .qml files relate and integrate with Python.
• QML uses JavaScript for things like placing items relative to a border or another item, or replacing a string with a given variable. Since I’d prefer not to learn both QML and JavaScript just to build a GUI, I’m investigating how much of this logic can be done in Python.
• Lastly, tying the database into the GUI seems to be handled differently than with classic Qt. I’m happy to see there are several Academy courses specifically covering this topic.

So far most of the courses have been elaborating on things I knew, which is good because I feel I have a firmer grasp on the core than before. Based on what I’ve learned I have some ideas on how to go back and improve the components I made earlier.

Honing the Flow

Next I want to go over a little bit more about how I’m imagining the flow of different projects.

For the initial release I’ll limit things to just three columns per board: Backlog, In Progress and Done.

Moving Tasks

When an item is in In Progress it has two possible moves: it can go forward and be marked as Done, or it can go back and return to the Backlog.

Initially I thought that having both available through buttons per task would be the smoothest. But after some thought, and sketches, that seems like visual (and mental) overload.

Reducing Visual/Cognitive Noise

Maybe instead the button to move a task back should be with the other details, where you’d already be thinking more deeply about the task.

The reason is that if you learn that a task you thought you could work on is actually not ready for some reason, you will almost certainly need to change its details - the description, due date, etc. So, by putting the move back option with the details view it would encourage addressing both at once.

It will also keep the main column views less cluttered/noisy.

Another question in the same vein: where should tasks that are sent-back go in the queue? One option is to put them at the top, since they just moved from the top and can be assumed to be high priority. Or they could go to the bottom, reinforcing that they aren’t workable right now, and encouraging a holistic review of the Backlog.

Currently I’m leaning towards moving bumped back tasks to the bottom, and putting a button to move the task back to the Backlog in the detailed view. (Though there may be a middle-ground of still displaying them at the top but exempting them from pulls until the user says they’re ready to go again.)

If you have thoughts on what might work best, I would love to hear your insight - contact me below!

Multi-step Projects

Another topic I’ve been considering is how to handle projects with multiple phases.

For example, I helped some friends who were working on a writing project, where there were lists/stages for: initial ideas, rough drafts, edits, second draft, editor review, collect for publication, published, etc.

It’s obvious that a process with this many stages can’t fit cleanly into the simple To Do overview.

So I’m planning a feature that acts like a focused viewport into these boards - a way to show only the active In Progress stages, without the Backlog or other distractions. Here is how it might look next to the overview:

And focused just on the multi-step board:

I would love to hear your experience working with Kanban Boards that have multiple In Progress columns. What would you need, or want, to see at a glance to keep things moving, without getting distracted?

Takeaways

Don’t be in too much of a rush - if you can move quickly on something that’s great, but if you find that you’re not getting the quality or progress you wanted - take a step back to determine why. Sometimes slow is fast and a solid grasp on your tools will pay off more than rushing for progress.

Call for Feedback

What do you think would work the best for how you work when you need to move a task back to the Backlog?

What do you need or want immediately accessible when managing a board with multiple In Progress steps?

Next Time

Next week is a holiday week, and I have some unavoidable external responsibilities - so I won’t be putting up a new post. I hope to follow up soon after that with more about how the PyQt6 + QML integration is going.

Photo Credit: Photo by imsogabriel stock on Unsplash