Enable manual path entry in the new profile assistant

[tleedjarv]

This is a complete fix for #1116. The GUI currently does not allow skipping the assistant (one can manually configure the profile more freely once past the assistant). This patch adds optional manual entry for sync paths so that more advanced users can get through it with less hassle.

[tleedjarv]

(CI fails not related to the PR.)

[Drugoy]

Did CI produce a build as an artifact? It looks like it did not.
Without it - I'm sorry, I can't test: this project has a build script from different millennium, which I hardly understand how to make it work:
I tried to follow the docs and execute just make (after installing some packages like ocaml and make [which I deduced are essential, but are not mentioned in the readme]), but got an error related to something macos (I am on linux):

ocamlopt: osxsupport.c ---> osxsupport.o
ocamlopt -g -I lwt -I ubase -I system -I system/generic -I lwt/generic -I +unix -I +str      -ccopt '-o '/root/gits/github/tleedjarv/unison/src/osxsupport.o -c /root/gits/github/tleedjarv/unison/src/osxsupport.c
In file included from /usr/lib/ocaml/caml/config.h:57,
                 from /usr/lib/ocaml/caml/mlvalues.h:22,
                 from /root/gits/github/tleedjarv/unison/src/osxsupport.c:4:
/usr/lib/gcc/x86_64-alpine-linux-musl/14.2.0/include/stdint.h:9:26: error: no include path in which to search for stdint.h
    9 | # include_next <stdint.h>
      |                          ^
In file included from /usr/lib/ocaml/caml/mlvalues.h:23:
/usr/lib/ocaml/caml/misc.h:29:10: fatal error: stdlib.h: No such file or directory
   29 | #include <stdlib.h>
      |          ^~~~~~~~~~
compilation terminated.
make[2]: *** [Makefile.OCaml:206: osxsupport.o] Error 2
make[2]: Leaving directory '/root/gits/github/tleedjarv/unison/src'
make[1]: *** [Makefile:42: all] Error 2
make[1]: Leaving directory '/root/gits/github/tleedjarv/unison/src'
make: *** [Makefile:22: src] Error 2

I then tried to figure out how to narrow the scope of stuff it attempts to build and decided that what I needed was just make gui and that way I got a different error:

# make gui
cd src && make gui
make[1]: Entering directory '/root/gits/github/tleedjarv/unison/src'
GUI library lablgtk not found. GTK GUI will not be built.
Not on macOS. macOS native GUI will not be built.

Building for Unix
NATIVE = true

make -f Makefile.OCaml gui
make[2]: Entering directory '/root/gits/github/tleedjarv/unison/src'
ocamlopt: pixmaps.ml ---> pixmaps.cmx
ocamlopt -g -I lwt -I ubase -I system -I system/generic -I lwt/generic -I +unix -I +str -I +lablgtk3 -I +cairo2   -c /root/gits/github/tleedjarv/unison/src/pixmaps.ml
File "/root/gits/github/tleedjarv/unison/src/pixmaps.ml", line 261, characters 2-31:
261 |   Gpointer.unsafe_create_region ~path:[|1|] ~get_length:(fun _ -> sz) buf
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Error: Unbound module Gpointer
make[2]: *** [Makefile.OCaml:202: pixmaps.cmx] Error 2
make[2]: Leaving directory '/root/gits/github/tleedjarv/unison/src'
make[1]: *** [Makefile:42: gui] Error 2
make[1]: Leaving directory '/root/gits/github/tleedjarv/unison/src'
make: *** [Makefile:28: gui] Error 2

I don't understand what's wrong here.
Just as some debug info how I got the above:

podman run -it --rm alpine sh

and then inside:

apk update
apk add ocaml git make
git clone --single-branch --branch fix-1116 'https://github.com/tleedjarv/unison.git' ~/gits/github/tleedjarv/unison
cd ~/gits/github/tleedjarv/unison/
make     # the first failed attempt
make gui # the second failed attempt

edit: I also tried building in a debian-based container, but got the same result.

[tleedjarv]

Did CI produce a build as an artifact? It looks like it did not.

Yes, yes it did. Are you not able to see the artifacts? If you do not see them directly then you have to click on 'Summary' or on 'CI' (the link name is different depending on where you start from).

Without it - I'm sorry, I can't test: this project has a build script from different millennium, which I hardly understand how to make it work: I tried to follow the docs and execute just make (after installing some packages like ocaml and make [which I deduced are essential, but are not mentioned in the readme])

I fail to see why you'd need to understand the build script at all. You seemed to have followed the wrong docs if you missed the essentials; they're pretty hard to miss.

but got an error related to something macos (I am on linux):

No, not related to macos. The errors are about stdlib.h and stdint.h.

I then tried to figure out how to narrow the scope of stuff it attempts to build and decided that what I needed was just make gui and that way I got a different error:

The error is explained in the output, though. "GUI library lablgtk not found. GTK GUI will not be built."
You need to install ocaml-lablgtk3 (Alpine) or lablgtk3 (Debian-based). But it doesn't matter now, the build would still fail with the same error about stdlib.h and stdint.h as above. I have no clue what those are about.

apk update
apk add ocaml git make
git clone --single-branch --branch fix-1116 'https://github.com/tleedjarv/unison.git' ~/gits/github/tleedjarv/unison
cd ~/gits/github/tleedjarv/unison/
make     # the first failed attempt
make gui # the second failed attempt

edit: I also tried building in a debian-based container, but got the same result.

That should work (provided lablgtk3 is installed). The error you're seeing is not coming from Unison's code. It would be of great help if you could figure out why you're seeing the error you're seeing. Could it be an issue with gcc or musl installation or the environment? Are you seeing the same error in Debian, too, or did you refer to the missing lablgtk only?

[Drugoy]

I feel a bit embarrassed, but I don't understand where to look for the artifact files.

[tleedjarv]

There are two ways to get to the artifacts. Either click on any of the 'Details' links you see and then on 'Summary' on the left hand side. Or click on 'Checks' on the very top of the PR (above first comment) and then click on 'CI' on the left hand side.

[Drugoy]

Thank you for educating me! I'd never find that myself.
I've tested - and functionally it now seems to work, but the wording (fields are called 'First directory' and 'Second directory' even when now they don't necessarily need to be directories) and visuals (a button that transforms the form by adding 2 text fields to the left from file pickers) are IMO weird:

But since it now indeed permits the user to use GUI to create a file-to-file sync - I am content with the patch.
Thank you!

[gdt]

Are you suggesting

• use "path" instead of directory?
• when clicking "manually", remove the picker widgets?
  or do you mean something else?

[Drugoy]

I'd suggest some wording like "file or directory".
As for the button - I'd suggest to:

• remove that button completely
• make the fields for the text paths always displayed and occupy the whole line
• shrink the drop-down-list button into a a small square (like 24 x 24 px) icon, working as a button that simply opens a file picker, - that should be capable of selecting either files or directories
• when the user confirms their choice in the file picker's window by hitting 'select' button - the selected element's path should simply get pasted into the corresponding text field

Another nitpick would be to limit the 2nd file picker's scope to the type (dirs XOR files) selected for the 1st field, to avoid a possible collision of user erroneously creating a file-to-dir sync.

[tleedjarv]

As for the button - I'd suggest to:

• remove that button completely
• make the fields for the text paths always displayed and occupy the whole line

But why? Are you suggesting that most users would want to enter the paths manually? Has this something to do with wanting to sync single files or do you just think that the assistant has always been wrong? I'm not specifically against this change but it needs to be motivated. (Or maybe you have good examples of how it's been done in other software?)

• shrink the drop-down-list button into a a small square (like 24 x 24 px) icon, working as a button that simply opens a file picker, - that should be capable of selecting either files or directories

That is not possible (as far as I know), as I already wrote in the other ticket. This is a limitation of GTK (and possibly native pickers). You can make it choose either files only or directories only.

• when the user confirms their choice in the file picker's window by hitting 'select' button - the selected element's path should simply get pasted into the corresponding text field

Just to be clear, that's how the patch works currently.

Another nitpick would be to limit the 2nd file picker's scope to the type (dirs XOR files) selected for the 1st field, to avoid a possible collision of user erroneously creating a file-to-dir sync.

It may make sense for the assistant, but I'm not going to spend any effort on this. If a user accidentally ends up with such a collision then they can simply cancel the first sync and either modify or delete and recreate the profile.

[Drugoy]

But why? Are you suggesting that most users would want to enter the paths manually? Has this something to do with wanting to sync single files or do you just think that the assistant has always been wrong? I'm not specifically against this change but it needs to be motivated. (Or maybe you have good examples of how it's been done in other software?)

No, I believe most users would use the button to open a dir/file picker, rather than specify the path manually.

That is not possible (as far as I know), as I already wrote in the other ticket. This is a limitation of GTK (and possibly native pickers). You can make it choose either files only or directories only.

What a weird limitation. All my further suggestions were based on this point, they don't make much sense if it's truly impossible to make a file picker allow users to select ANY(dir,file).
If that's the case - I think it's okay to leave things as they are in the patch.

[tleedjarv]

I looked into implementing your first suggestion but I don't know how to make it happen with GTK. The file picker button has a mind of its own and will not allow it to be constrained into a button. (It may be possible, I just don't know how.) Alternatively, it could be possible to use a regular button and make it open the file chooser dialog, but I don't think lablgtk exposes the API for that. Examples from other software could help, otherwise the only thing I can do right now is to remove the "enter paths manually" button (so the text fields are always visible). @gdt any preference?

[gdt]

Honestly I'm not sure it's really a good idea to put this in profile creation at all, but I don't feel that it's reasonable to object. As I see it unison synchronizes trees rooted at a directory, and while it works with files, that's a special case that to me feels degenerate. So people editing the config file seems fine, but I'm a command line, ed(1) type and I know I'm not typical. The UI as it is in the PR I find confusing (well, I know what is there and why, but I think it would be confusing).

Two separate thoughts:

• If we are going to allow entry of path rather than 'directory', we should change the language, but that raises the issue of the user understanding what path means -- even though path is plain language in the context of POSIX and in the manual.
• I wonder if the "directory selection screen" should be much as it was, with a checkbox/button "I want to synchronize two files, rather than two directories" that when pushed, navigates to "File Selection" instead, with two text boxes, and Next takes you to Specific Options, just as next from directory would. That leaves directory selection as directory selection, and a screen that is cleanly path selection. Alternatively if the checkbox is selected, mutate the screen to change it into what the 2-manual-paths screen would look like, and if it's unchecked, mutate back.

I realize my 2nd suggestion seems like work, but I think it will avoid confusing people. It also hoists the hint, which I like to avoid, into the checkbox of "sync two files rather than two directories".

[tleedjarv]

Well... your second thought is actually almost what I had in mind initially, yet didn't want to implement due to thinking it would be more confusing to users.

Now that I think about it, in that case we don't need text entry boxes at all. The checkbox can simply mutate the type of file choosers between dir/file.

[Drugoy]

Or maybe even a radiobutton with 2 states "Sync 2 dirs" and "Sync 2 files"?

[tleedjarv]

I went ahead and implemented what I initially didn't want to implement. But the effort is now spent anyway, so oh well. In the end, while the code is a bit more complicated now, I actually kind of like the outcome. Have a look and see what you think.

[Drugoy]

I think it looks way better now.
There's only that tiny bug where one can select a dir first and then switch to files and select a file for the 2nd location and thus get into dir-to-file erroneous config.
Flushing fields values when switching between dirs and files would be a pretty good solution for that problem.
But that is actually just a step to make a program a bit more fool-proof, I don't know if you share this ideology.

[gdt]

This is great; the display is really easy to understand. Putting the file/directory in a menu is genius; it reads naturally and screams at the reader that it can be changed, and thus there's no giant hint for an odd situation demanding to be be read - once you've grasped that you can ignore it, if you're a sync-dirs type. Or not, if you like files.

I tested clicking around a bit, and the only thing I found, which is minor, is that switching file->dir not only leaves the file, but it ends up in the gtk picker's history so you can go to a dir and then back to the file. But, things are overall vastly better than they are now, so I'm ok with merging with that nit, and I'm ok with another force push. Let me know.

[tleedjarv]

I don't think I'm going to do anything about the file-dir mixup issue. I don't want to blindly clear the selections (I really dislike software that does this -- if I want to simply explore what some option does and then all my configuration is wiped clean, that's a big no-no). Adding the complexity of actually stat-ing whether something is a file or dir does not seem reasonable either. In the end, even if there is a mixup, nothing will directly break, even if it is an inconvenience for the user.

If this turns out to be a nuisance for users then we can come back to it.

[gdt]

Your logic makes sense and that works for me. So ready to hit merge?

[tleedjarv]

As far as I'm concerned, ready to merge.