QEP: Overview of widget types while configuring forms #318
Conversation
|
Regarding "form preview" -- how will this be coded? Will you add API to allow showing forms with a specific edit form configuration, or will the changes be applied to the layer first? I'd much rather the former approach, that API sounds like it would be quite useful (and would eg pave the way for multiple form configuration for a layer) |
|
|
||
| Switch from current item-based tree widget to model-based tree view to ease maintenance and gain flexibility. | ||
|
|
||
| Use the form layout item’s decoration role (i.e., item’s icon) to show its type of widget. This is appropriate because all items will have one and only one type of widget. |
There was a problem hiding this comment.
I really don't think that using icons is the best choice for this. There will be way to many icons for users to easily distinguish and identify (more than 25 if you include containers and Other widgets) and the list may grow in the future.
Also, having different icons in for each field in both Available Widgets and Form Layout views can be overwhelming and confusing.
I'd rather have this as plain text, possibly on a separate column in Form Layout.
There was a problem hiding this comment.
Yes, it would be a challenge to create the set of icons for this. Fortunately, @nirvn would be in charge.
We've thought about additional columns as well, but for the moment would like to avoid them if possible due to the lack of space in that part of the UI.
Anyway, lets see what others think about it.
There was a problem hiding this comment.
I'd prefer the icon over text in an additional column which would take too many place. Still, there is a challenge to make clean and recognizable icons.
The new API would be the way to go in this case. |
qep-401-overview-widget-types.md
Outdated
|
|
||
| + **Filter/search box**, taking advantage of the model-based tree view. | ||
|
|
||
| + **Form preview**, to give users the option to see what they'll get easily and in the right place, i.e., without having to follow additional steps like closing Layer properties, enabling editing and adding a feature just to see what they've just configured in action. The preview will be opened in a new window, parented to the Vector Layer Properties dialog. |
There was a problem hiding this comment.
Instead of having another windows preview, could we not just update the real form when user clicks on Apply button ? It's actually the case when you change the widget, but not when we change the alias for instance.
If it was working for any parameter you can modify, it would solve the preview issue in an even better way, because it would be populated with real data.
There was a problem hiding this comment.
We haven't really aimed at changing existing QGIS behavior on opened forms. The form preview will only be shown as a child window of the Vector Layer Properties dialog. Users could preview the configured form without leaving that dialog, i.e., without having to open the attribute table's form view or to add a new geometry.
There was a problem hiding this comment.
I understand but it's just yet another window (and more code) when there is actually one existing, already populated with relevant data so you can better look about what it really look like.
Do you plan to populate this preview window with a feature like what we are doing for expression evaluation for instance, or it's more like the Qt designer empty preview?
There was a problem hiding this comment.
Fair question about how the form will be populated with data.
Regarding the proposal to reuse the "real" form, I wonder if that's a good experience. The layer properties dialog (where widgets/forms are configured) is a modal dialog, so it won't be possible to open a form through the main window and already open forms will be stacked behind the layer properties and not interactive. I am not sure we can realistically reuse these.
There was a problem hiding this comment.
Fair point too... I tested it before posting my comment but I was actually using dual screen.
I like current behavior with dual screen though
here we see that form is not refresh when alias is modified, but only when widget type is.
We could also do like we do with map symbology and display widget editor beside the attribute form when hitting F7 and refresh the form as soon as user modify a parameter.
There was a problem hiding this comment.
Do you plan to populate this preview window with a feature like what we are doing for expression evaluation for instance, or it's more like the Qt designer empty preview?
I guess I always had this Qt-designer's empty preview in mind (i.e., that would already be great), but adding sample data to the preview in the same way that it is done for previewing expressions results sounds awesome.
Of course, we won't have a Save button available there, but the rest could look like a real input form. That is, widgets wouldn't be set to read-only mode (unless the widget config says so), but any changes to the sample data wouldn't be applied.
There was a problem hiding this comment.
Do you plan to populate this preview window with a feature like what we are doing for expression evaluation for instance, or it's more like the Qt designer empty preview?
Suggestion applied in bcd86d4, thanks!
We could also do like we do with map symbology and display widget editor beside the attribute form when hitting F7 and refresh the form as soon as user modify a parameter.
With respect to this, it looks to be in line with what @saberraz suggested for future iterations.
We'd consider moving the UI to a docked panel a bit out of scope for now.
|
Nice proposal @gacarrillor 👍 |
|
This will be a great feature. In ideal world, we should have a separate window (similar to print composer or model builder) to handle forms and tables. It would allow users to create relations graphically, select widgets, preview forms, create a new table using widgets directly (similar to Google forms), etc. The current state under layer properties is limiting in a long term and is not scaling well with all the great functionalities being added constantly to forms. I understand your scope is limited, so the this might be out of consideration. |
Thank you @troopa81. |
Nonetheless, those are good guidelines to keep in mind, thank you! |
QEP to add some UI/UX enhancements when configuring forms and/or wanting a glimpse on what's already configured.
Since the QEP process is being refactored, we're open to adapt this PR to any given format :)