[Problem] Creating a shapestring is difficult and confusing

[sliptonic]

Is there an existing issue for this?

• [X] I have searched the existing issues

Version

0.21 (Development)

Full version info

[code]
OS: Linux Mint 20 (i3/i3)
Word size of FreeCAD: 64-bit
Version: 0.21.0.33029 +1 (Git)
Build type: Unknown
Branch: (HEAD detached at upstream/pr/9418)
Hash: bfcc5d029f2dfbce0be1c240363ef015dbd7d3c4
Python 3.8.10, Qt 5.12.8, Coin 4.0.0, Vtk 7.1.1, OCC 7.5.2
Locale: English/United States (en_US)
Installed mods: 
  * DynamicData 2.46.0
  * Assembly4 0.12.5
  * fasteners 0.4.55
  * Behave-Dark-Colors 0.1.1
  * 3DfindIT 1.2.0
  * Render 2023.2.2
  * ProDarkThemePreferencePack 1.0.0
  * sheetmetal 0.2.59
  * QuickMeasure 2022.10.28
  * Nodes 0.1.36
  * FeedsAndSpeeds 0.5.0
  * Assembly3 0.11.4
  * ExtremeProDark 2.6.4
  * FeedsAndSpeeds.bak
  * Curves 0.6.5
  * A2plus 0.4.60k
  * Dracula 0.0.2
[/code]

Subproject(s) affected?

Draft

Problem description

The ShapeString dialog is poorly designed and implemented. As a result, creating a shapestring is difficult and confusing.

Specific problems to be addressed in this issue:

The organization of the panel is unintuitive.

• The point is to create a string but the string input field is halfway down the task panel. It is the thing that is top-of-mind for the user so it should be the first input field.
• The font file should be the second input.
• The Height should be the third input.
• The string input feature contains default text of the word 'default' This should be a placeholder text with the string 'enter your string' or similar. As long as the string input field is unpopulated, the Apply/Ok buttons should be disabled.
• Font file input is unpopulated and requires the user to select a file rather than a font.
• 'reset point' control is confusing

The dialog does not provide realtime feedback. It should preview the shapestring in the 3D window

Anything else?

Forum discussion: https://forum.freecad.org/viewtopic.php?t=77718

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

[sliptonic]

Based on forum discussion, the selection of a font vs font-file is more difficult. I've created a separate issue to track that problem. https://github.com/FreeCAD/FreeCAD/issues/9458

[sliptonic]

If font selection is a harder problem, one workaround would be appreciated. The dialog could find the system installed fonts, and pre-select the first font. Then if the user wants to change the font file, there's a high likelihood that they are at least in the correct system folder.

[Roy-043]

in the correct system folder

On Linux systems many font folders can exist.

[sliptonic]

in the correct system folder

On Linux systems many font folders can exist.

Pick one. It's got to be a better guess than what we have now

[adrianinsaval]

The dialog does not provide realtime feedback. It should preview the shapestring in the 3D window

is this safe to do? no hang expected even with complex and/or selfintersecting fonts?

[yorikvanhavre]

Maybe another point to consider is that the dialog layout should reflect the same order of what the user is supposed to do. If we are going to show a preview of the font on screen, we probably need the user to pick a position first so we have a place to display the text. In that case, the coordinate fields should come first too IMHO

[yorikvanhavre]

Pick one. It's got to be a better guess than what we have now

I disagree on that point. This might confuse users a lot more if only half of their fonts is displayed, and there would be no way for them to fix it, as opposed to now, where at least they can go manually pick the right font file

[adrianinsaval]

Maybe another point to consider is that the dialog layout should reflect the same order of what the user is supposed to do. If we are going to show a preview of the font on screen, we probably need the user to pick a position first so we have a place to display the text. In that case, the coordinate fields should come first too IMHO

personally I find it easier to place things when I can see the geometry I'm moving, so I would write the text, choose a font and at least an estimate of the size before moving it, then once in place check if the size was correct (assuming I'm eyeballing it rather than having predetermined it)

[sliptonic]

Pick one. It's got to be a better guess than what we have now

I disagree on that point. This might confuse users a lot more if only half of their fonts is displayed, and there would be no way for them to fix it, as opposed to now, where at least they can go manually pick the right font file

Something is better than nothing. Always. Not seeing ALL the fonts is a different problem. We don't make that problem less by showing them NO fonts.

Maybe another point to consider is that the dialog layout should reflect the same order of what the user is supposed to do. If we are going to show a preview of the font on screen, we probably need the user to pick a position first so we have a place to display the text. In that case, the coordinate fields should come first too IMHO

I agree with @adrianinsaval. You can make a decent guess at location. Heck, 0,0,0 is a pretty good guess. Or you could guess the middle of the view window. The point is that it's easier to refine the guess than to enter coordinates given nothing at all.

You can't make a good guess at a string though. The user MUST enter that. Given a string, we could guess everything else and show the user something to refine. That's a much friendlier workflow.

[yorikvanhavre]

personally I find it easier to place things when I can see the geometry I'm moving, so I would write the text, choose a font and at least an estimate of the size before moving it, then once in place check if the size was correct (assuming I'm eyeballing it rather than having predetermined it)

Yes, that seems good indeed... The preview could simply move together with your mouse. The logic for that could actually be used by Draft_Text too...

Something is better than nothing. Always. Not seeing ALL the fonts is a different problem. We don't make that problem less by showing them NO fonts.

You are replying only half of my observation: there would be no way for them to fix it, as opposed to now, where at least they can go manually pick the right font file.

I'm not saying we don't do nothing, I'm saying we need to do it right, not half-baked

[sliptonic]

You are replying only half of my observation: there would be no way for them to fix it, as opposed to now, where at least they can go manually pick the right font file.

I'm not saying we don't do nothing, I'm saying we need to do it right, not half-baked

Ok, I didn't understand.
What I'm saying is that we're half-baked now. Going to 3/4 baked on our way to fully baked is ok. If the interim solution isn't the perfect one, that's fine.

I was proposing that as a worst-case approach:

1. use the system utility to derive the list of font locations
2. take the first location
3. take the first font
4. populate the font file input with the filename/path

The user can still choose a different one, just like today. If they decide to choose a different font, which they almost certainly will, the file selector will start out in one of the font locations so there's a decent shot it's right.

[mfraser]

I've also found that the font path changes on Linux depending on how it was installed. Flatpak seems to point to /run and AppImage starts off in /tmp. When you load a file created by Flatpak in AppImage or deb and then change the shapestring, you get an error.

[leoheck]

Preselecting a font from the system is a trivial task. Remembering the last used font is also a trivial task.

Having a font from the system selected helps the user to find the others quickly since when he launches the file browser will start from that place.

If It is really hard to preselect a font from the system (which is not). Then another solution would be Freecad having one or a set of fonts. This can be also interesting so the initial font on every system can be the same.

[Roy-043]

New development: #16928.

[Roy-043]

Another development: #22217.