Add unified panel for input or algorithm in the modeler
Description
This PR unite the Inputs and Algorithms panel under a single panel by moving the model parameters into theirs own sub category in the toolbox in the context of the modeler.
This feature avoid the annoyance to switch between the two panels back and forth. Additionally the model parameters are now searchable as well !
Thanks to the Hauts-de-France region for sponsorising this work and Camptocamp for their collaboration
Before the PR:
After the PR:
🪟 Windows Qt6 builds
Download Windows Qt6 builds of this PR for testing. (Built from commit af6fd2327dbbf30f958e1a122ac3fc8c264d5fd3)
🪟 Windows builds
Download Windows builds of this PR for testing. Debug symbols for this build are available here. (Built from commit af6fd2327dbbf30f958e1a122ac3fc8c264d5fd3)
@ValentinBuira , hey there, I think it's the first time I'm commenting on a PR of yours, nice to meet your code! ;)
On this PR, I'm -1 to remove the algorithm and parameters panels. I have a fairly large screen, and I much prefer to have both panels opened side by side (one above the other) and keep these separated.
Now, I can also see an argument for people who want things merged together (small screen size, or just a subjective preference). What I'd propose here is for you to keep the alg. and parameters panels as is, and add a new panel (maybe call it toolbox, or components) that will have a tree structure like this:
- Parameters
- Vector layer
- Vector feature
- etc...
- Algorithms
- Vector creation
- Random points
- Random lines
- etc...
- Vector analysis
- Difference
- Union
- etc...
- etc...
Having categories as root notes makes for a cleaner presentation and allows for more components / types to be added in the future (say we have conditional nodes for e.g.).
I'm not against finding a way forward on this, and I very much appreciate your efforts. We just have to make sure it will be satisfactory for all and future proof :)
Hi @nirvn thanks for your feedback
The design is based of the Google Summer of code proposal I did last year, and that we discussed on the mailling list.
As it stand, I am not that keen to duplicate panel that would be so similar in functionalities. In this PR I have been mostly following existing practice within the modeler for example:
Having categories as root notes makes for a cleaner presentation and allows for more components / types to be added in the future (say we have conditional nodes for e.g.).
In fact this already exist with the "Modeler tools" and is integrated in the algorithm panel as well. (It's even a bit more hidden as the icon is the same as algorithm)
I don't know what do you think about it @nyalldawson ?
I tend towards @nirvn's opinion that this isn't a universal "win". It will definitely improve some workflows, but I do think it comes at the cost of a bit less user-friendliness. Users will have to seek out the "model parameters" group, whereas the existing approach just puts these right in their faces. So in my view it's a win for some experienced users, but a step backwards for QGIS beginners.
That's why I'd personally like something like @nirvn's proposal. We add the "model parameters" group to the algorithms list, rename this as "toolbox", but keep the existing "inputs" panel available (and visible by default). We then remember the state of this panel, so if a user doesn't want it they can close it and it'll be closed for all future sessions.
Let's bring @alexbruy , @andreasneumann , and @DelazJ into the conversation too -- they'll all have valuable feedback.
I also think that we should keep existing "Inputs" panel available at least for some time. While having a single toolbox with inputs and algorithms can be more comfortable in some cases, in other cases having a separate panel is more useful.
I understand than the consensus is to keep the two panels at least in some form.
So, I made a synthesis of your comments:
- The "Inputs" panel would be kept as is, and the reorder inputs button still belong to this panel
- The algorithms panel is turned into a "Toolbox" panel and is embellished with a new sub categories "Input parameters" that is now searchable along side other model component. The parameter inside the toolbox behave as you would expect with double click and drag and drop to add it to the model
See at the bottom of the for a screenshot of the current state
If the design is settled then it's ready for a proper review.
Design looks good to me (except "inputS parameters" in the tree should be just "input parameters")!
@nirvn thoughts?
except "inputS parameters"
Englishing is hard sometimes :-) Fixed thanks
The QGIS project highly values your contribution and would love to see this work merged! Unfortunately this PR has not had any activity in the last 14 days and is being automatically marked as "stale". If you think this pull request should be merged, please check
-
that all unit tests are passing
-
that all comments by reviewers have been addressed
-
that there is enough information for reviewers, in particular
-
link to any issues which this pull request fixes
-
add a description of workflows which this pull request fixes
-
add screenshots if applicable
-
-
that you have written unit tests where possible In case you should have any uncertainty, please leave a comment and we will be happy to help you proceed with this pull request. If there is no further activity on this pull request, it will be closed in a week.
This PR is still active and waiting for a review
Ping @nirvn, do you think you could have a second look at the design ?
Looking good to me, thanks for being responsive to our requests @ValentinBuira
I corrected the last comments review, and it's ready to be merged, thanks all for your involvement
@ValentinBuira Thanks for your contribution. Can you double-check whether the top message is inline with the final implementation so that we could appropriately label the PR for changelog and documentation, please? Same applies to #60664. Thanks
@ValentinBuira Thanks for your contribution. Can you double-check whether the top message is inline with the final implementation
Thanks @DelazJ, I have updated the PR description to match the end implementation. And for #60664 it stayed the same
@ValentinBuira This pull request has been tagged as requiring documentation.
A documentation ticket will be opened at https://github.com/qgis/QGIS-Documentation when this PR is merged.
Please update the description (not the comments) with helpful description and screenshot to help the work from documentors. Also, any commit having [needs-doc] or [Needs Documentation] in will see its message pushed to the issue, so please be as verbose as you can.
Thank you!
@ValentinBuira
This pull request has been tagged for the changelog.
- The description will be harvested so please provide a "nearly-ready" text for the final changelog
- If possible, add a nice illustration of the feature. Only the first one in the description will be harvested (GIF accepted as well)
- If you can, it's better to give credits to your sponsor, see below for different formats.
You can edit the description.
Format available for credits
-
Funded by NAME -
Funded by URL -
Funded by NAME URL -
Sponsored by NAME -
Sponsored by URL -
Sponsored by NAME URL
Thank you!
@ValentinBuira A documentation ticket has been opened at https://github.com/qgis/QGIS-Documentation/issues/9848 It is your responsibility to visit this ticket and add as much detail as possible for the documentation team to correctly document this change. Thank you!