[Resolved] PR #4942 new option to show/hide sketcher constraints

[uwestoehr]

Testing shows exactly this. I do not understand the confusion.

Here is again my recipe:
- restart FC
- choose "Datums" in the combobox"
- click the Hide button

result: the button hides only the datums, the rest is still visible

- now enable the tracking option
- click the hide button again

result: now everything is hidden, despite still only the datums are filtered
expected result: nothing visible happens since the datums are are already hidden

So the button behaves different in different situations and it is not clear for an average user what will happen.
With my proposal such cases should not occur and the button would in every case only hide what is currently listed in the list view.

[abdullah]

Note: Filter tracking means:
1. Upon checking the checkbox, adapt to the filter selection.
2. On every filter selection, perform automation to show just what is selected in the filter (i.e. to track the filter selection).
3. Between filter selections, obey the manual commands send via the buttons.

And here I see the problem. You automatize only one side. As user I want the full control - deciding what and how. So either I first select an object and then perform the action (hiding or showing) or I first define the action and then the object. The UI as it is, is to select first the object and then the action. This concept should be consistently used.

The tracking only shows the filtered objects, but never the other way round - everything than the filtered objects. Personally the latter is why I once made the PR. Sketches contain quickly too many objects and I need to hide some to keep the overview or to be able to discuss things.

So when tracking, then please both ways. Thus I opt to be able to select which tracking type is used, see my summary below.

If you want full control, then you do not want to use the "track option".

Tracking only shows the filtered objects, because it is tracking the selection to make the selection and nothing else visible. IMO it is having the intended behaviour.

I am no longer sure of what your PR did (I will have to compile it again). I think your PR allowed to hide/show the filtered objects. If this is accurate, your PR did not allow to operate the visibility of the non-filtered constraints (the constraints not in the list). If that is accurate, then forget the "track option" and use the "show"/"hide" buttons, that correspond to the functionality of your PR.

What you call "two side automatisation", is not tracking the filtered list. As far as I understood, you want to have a different behaviour for the buttons in this mode. This is what you inaccurately complain about in the next paragraph.

You may still get what you want if you enable "tracking" and select the complementary of the group you want to hide (selecting "Geometric" when wanting to see everything but datums). However, nobody is forcing you to.

4. Oh! We are Tracking, but the guy just told us to override the tracking by hiding all listed

Oh, FC is not following my will. I pressed the button to hide something, but I don't get what I want
I don't think that pressing the button should overwrite anything. A click of a button is the users will, so he wants the particular action the button promises. As I once learned, it is "bad UI" that the same button behaves differently when there is no prior visible feedback "Hey user, note, when you press the button now, it will behave other than with out the option". And over the years my experience it that this indeed confuses users a lot. (Of course this statement does not apply to the standard OK buttons of dialogs.) So at least the button text must change to indicate this.

However, I don't think this is necessary. The Hide button should always hide all constraints in the list, see below my summary.

Totally following your will. It is the same behaviour that outside the "tracking mode". You could not have expected any other behaviour. You told the thing to hide everything filtered and it complied (Datum were filtered, Datum were hidden). The same would had happen outside the tracking mode.

----------

A general UI remark: In FC we have 2 types of options:
- either an option performs an immediate action (e.g. the pad reverse option in PD)
- or a settings option
The tracker option however differs from this since it either have an immediate effect or not. This confused me a lot and I think we should avoid such a behavior.

----------

A "Show listed" / "Hide listed" is a good example of an action that does not require any selection per se.

Honestly I do not get this at all. Before the PR was merged, the constraint widget had two checkboxes ("Hide internal alignment" and "Extended Information"). Both of them generate the list to be refreshed on checking them (and it appears that this is what the user wants). Both of them set a state for future refreshes (how to act).

I think you are mixing the 3D view behaviour with the functionality inside the widgets. But most importantly, I do not understand why you are unhappy that the mode is immediately enforced, when you complained about it not being immediately enforced some posts ago (when I forgot to actually code this enforcing).

Summary of what I would change:
1. name the buttons "Hide listed constraints" and "Show listed constraints"
2. the buttons will in every case act the same - showing/hiding the listed constraints
3. the tracking option becomes a setting option, so it will not perform an immediate action when it is turned on
4. there will be a radio group to either turn on the option to track so that everything is hidden except of the filtered objects, or to track the opposite way, that only the filtered object is hidden

1. I will go with "Show listed" / "Hide listed"
2. This is what they do now.
3. I won't change this, as I think it is the correct behaviour.
4. I think this is not reasonable. Too many controls will only confuse the user. If you want to hide instead of showing, do not use the "tracking mode", just select in the filter what you do not want to see, and hit "hide listed". AFAIU, this corresponds to the functionality you wanted to provide in your PR.

[abdullah]

Testing shows exactly this. I do not understand the confusion.

Here is again my recipe:
- restart FC
- choose "Datums" in the combobox"
- click the Hide button

result: the button hides only the datums, the rest is still visible

- now enable the tracking option
- click the hide button again

result: now everything is hidden, despite still only the datums are filtered
expected result: nothing visible happens since the datums are are already hidden

So the button behaves different in different situations and it is not clear for an average user what will happen.
With my proposal such cases should not occur and the button would in every case only hide what is currently listed in the list view.

Do you realise that you are expecting a same result from a different sequence of events? If the sequence is different, the result may well be different.

The button does not do anything different. You start from a different situation when you hit the button.

In the first case you start with "All" the constraints being shown. In the second case you start with "Only the Datums" being shown. Hitting the button does exactly the same in both cases. The result is different because you start from a different situation.

In your PR, if you start from that distinctive situation, you will also get different outcomes (bugs aside, the same outcome that in current master).

[wsteffe]

In the last video there is an Automation Tab with a Tracking Checkbox inside of it.
And what does it make the Automation when Tracking is not checked ?

[uwestoehr]

Do you realise that you are expecting a same result from a different sequence of events? If the sequence is different, the result may well be different.

But this is my point: I click the same button, but it behaves differently depending on what happened before. And this is confusing.

Therefore my proposal is:
- the button always filters the listed constraints, nothing else

When you look at my example steps, I filtered the datums, so when I press the hide button, I expect the the datums to be hidden. If they are already hidden, then of course noting visible will happen. But as it is I filtered the datums, press the button but ALL is hidden.

I am aware that my PR was not thought to the end, so let's keep it aside. its functionality is now in thanks to your work, now I want to find a better UI and with better I mean something an average user understands without the need to reading the docs before.

[uwestoehr]

If you want full control, then you do not want to use the "track option".
Tracking only shows the filtered objects, because it is tracking the selection to make the selection and nothing else visible. IMO it is having the intended behaviour.

I understand meanwhile the idea of the tracking and I am not opposed. in contrary, I would like to extend it even further. So as it is, it works nicely for showing things I select. Fine and ready as a feature.

What I want now on top is to have a radio group in which I can change the tracking behavior. I want to benefit from it, but the other way round too - that what I select is hidden. For my daily use case this would be very valuable.

The tracker option however differs from this since it either have an immediate effect or not. This confused me a lot and I think we should avoid such a behavior.

Honestly I do not get this at all. Before the PR was merged...

I see that our misunderstandings arise because of the different things we speak about. So let me try to sort it out:

* let my PR aside, it is now obsolete
* let's aside what was there before the new features. Now we have cool new features and need to find an UI that suits us.
* the tracking feature is cool, I only want to extend it
* there are 2 UI things that I want to change, because they confuse my and that are in my opinion not self-explanatory:
** The button should _always_ just show hide the currently filtered constraints: no matter what happened prior to the button press. So when the button is pressed, it takes the constraints that are currently in the list view and shows/hide them (This was what my PR intended)
** enabling/disabling the tracking option should not result in an immediate action: It confused me and thus I guess also other new users, that sometimes enabling the option has an immediate effect, sometimes not. I expect the option as a setting - "hey computer, from now on please track the filtering I do." And when you disable "hey, now you can stop tracking"

I hope this clarifies a bit.

So let's maybe first decide, if you are open to extend the tracking feature as I request or not. Then we have one topic less.

[abdullah]

Do you realise that you are expecting a same result from a different sequence of events? If the sequence is different, the result may well be different.

Therefore my proposal is:
- the button always filters the listed constraints, nothing else

When you look at my example steps, I filtered the datums, so when I press the hide button, I expect the the datums to be hidden. If they are already hidden, then of course noting visible will happen. But as it is I filtered the datums, press the button but ALL is hidden.

Look Uwe, we really need to get to a common understanding on this point before discussing anything else. I will not discuss any other UI element until we arrive to a common understanding on these specific buttons.

What you are saying does not make any sense to me. This can be because I misunderstand you or because you misunderstand me. I am open to all angles.

Please, reply "True" or "False" and "wanted" or "unwanted" (two replies per statement).

IN THE CURRENT MASTER...

First statement: "The button with current label show-all always always always ensures that the listed elements are shown" (true or false)
Second statement: "The button with current label hide-all always always always ensures that the listed elements are hidden" (true or false)
Third statement: "The buttons show-all and hide-all only change the visibility of the listed elements, they do not alter the visibility of the non-listed elements" (true or false)
Fourth statement: "Because the buttons only operate on the listed elements, the final result of hitting one button depends on what was shown before that button is pressed. In particular, if non-listed elements were not visible they will remain not visible. If non-listed elements were visible they will remain visible.".

I hope that the answer to these four statements is "True" and "Wanted". If this is not the case, we do have a problem of definition of what the buttons should do. This problem is dire because they will be called "show listed" and "hide listed". I cannot understand that these buttons do anything else that what is described above. We can speak other buttons, checkboxes and UI elements. But we must reach the understanding that these buttons are currently doing what they should do, what they claim they do and what we expect them to do. Otherwise, there is no moving forward.

[uwestoehr]

Please, reply "True" or "False" and "wanted" or "unwanted" (two replies per statement).

Good idea since I think we only have misunderstandings.

I took master from half an hour ago and recompiled from scratch to assure that I have a clean system.

So here are my replies:

> First statement: "The button with current label show-all always always always ensures that the listed elements are shown"

True
wanted: rename the button text

> Second statement: "The button with current label hide-all always always always ensures that the listed elements are hidden"

True
wanted: rename the button text

> Third statement: "The buttons show-all and hide-all only change the visibility of the listed elements, they do not alter the visibility of the non-listed elements"

True
wanted: is fine as it is

> Fourth statement: "Because the buttons only operate on the listed elements, the final result of hitting one button depends on what was shown before that button is pressed. In particular, if non-listed elements were not visible they will remain not visible. If non-listed elements were visible they will remain visible."

True
wanted: is fine as it is

So the buttons are almost fine as they are. The issues I had must have come from my maybe unclean local master or you fixed something within the last 2 days.

For the tracking I still want to extend this feature, but let's skip this to a further discussion -> I will open a new thread just for this.

[abdullah]

For the tracking I still want to extend this feature, but let's skip this to a further discussion -> I will open a new thread just for this.

Not necessary. Now that we are on the same page, we can talk here.

[uwestoehr]

Not necessary. Now that we are on the same page, we can talk here.

I is hard for others to step through such a long thread that begun with a PR.

In general I would like to have a devel subforum, like e.g. TechDraw has:
https://forum.freecadweb.org/viewforum.php?f=35

Then we have a space to discuss only sketcher-related things and don't need to post in the general Help or developer forum. If you agree, I could set this up. Note that this does not mean to have more work, it is only a subforum that devels interested in Sketcher things have a place and one has the advantage that one can subscribe to the subforum. Then one gets informed whenever a new topic is opened there, and only there.

So would it be OK to create a developer subforum for sketcher? And to make there the first new topic the tracker feature request?