New. Stuff. Action!

In my last entry, one of the thing i spoke a bit about was how sometimes you run across places where a ui elements don't quite fit into a window and end up being cut off. One of the examples of this was how a row of buttons in a lot of our control centre modules would be too wide, and just end up outside the window. The way we solved that was to use Kirigami's ActionToolbar, which then semi-magically folds buttons into a little kebab-iconed overflow menu, and everything is lovely and works as expected.

A little kebab-menu which shows things for which we haven't otherwise got the room

Problem?

One detail i omitted from this was that how the QtQuick NewStuff components used to allow users to show things was either through manually creating a NewStuff.Dialog, or a NewStuff.Page, or the convenient shortcut that is NewStuff.Button. Now, if you are observant here, or otherwise familiar with the way KDE's software stack works, you'll notice that all of these things are items with a defined visualisation: Dialogues are explicitly a window with some buttons at the bottom (like the one in the screenshot above, and in the case of NewStuff.Dialog, there's a close button), Pages are things you can put into a QtQuick style Page Stack (such as the one found in Kirigami applications), and a Button is, well, a button.

The problem you run into when everything has a defined visualisation like that is, what do you do when you need to present the user with something else, such as in the case of that magic, folding set of controls up there? Well, in the original merge request for this problem, the solution was to manually create a NewStuff.Dialog, stored in a Loader to emulate the way NewStuff.Button doesn't try and load things until the dialogue is shown, and then create a separate Action entry in our new Kirigami.ActionToolbar which worked with that Loader. 

You'll notice by that description, and if you go and look at the code in the merge request itself, that this is considerably more work than it was to use the NewStuff.Button. What's needed to get around that is a new component in the QtQuick NewStuff components which has no representation of its own, and just gives you the functionality.

No, Solution!

Oh look, a Page, with New Stuff in it, i wonder what that component could be called ;)

Enter NewStuff.Action, a handy dandy little component which has no visual representation of its own, but will happily sit in a list of actions such as that used by Kirigami.ActionToolbar and look however that decides that it should look.

The API is very similar to NewStuff.Button, in that you set a text, a config file. For dealing with things having been installed or removed, use one of the signals which deal with entries changing (changedEntries remains for ease of porting, but the new entryEvent signal should be used whenever you can, as it's much more informative about what's actually happening and when).

Not only that, but while NewStuff.Button works deliberately very similarly to the old KNS3::Button control in that it opens up a Dialog, NewStuff.Action will do that by default, but if you tell it which pageStack to use, it will instead push a NewStuff.Page onto that page stack (and if it's able it will even switch back to that page if activated again).

Over To You

You may be looking at this and going "well, why are you telling me all this?". Here's the deal: The idea behind this is to allow others to more easily do the minor surgery that was allowing those things to fold out of the way when there isn't enough space. If you've been looking for some low hanging fruit to pick, here's a nice, ripe bunch for you :)

---

The word of the day is: Actionable. Because this kind of is ;)