Ordered by Topic

[gregsn]

I tried to reorganize things so that everything is ordered by topic. If this is done with collapsable headers we can fit everything onto the first tab. We would be able to get rid of the 3rd tab and also most of the menu items, as the commands are now buttons at those places where it's about a certain topic.

Main Tab:

vvvv version [Launch] 
[ ] Start new vvvv instance
[ ] Start stopped

> Installed vvvv versions
Installations Folder 
________________________ ... [Rescan]
[Uninstall Current] 

> Packages
[ ] ________________________ ... X
[Show] [Create Empty Folder]

> Source packages
[ ] [Show] ________________________ ... X 
+

> Editable packages
[ ] ________________________ X
+

> Debugging / Advanced
[ ] Extra commandline arguments 
    ___________________________
[ ] Debuggable target code
[x] Package compiler
[x] Package compiler may cache
[x] Editor extensions

remarks:
> Packages
if checkbox isn't checked: Show button shows the default Appdata folder.

Create Empty Folder creates a new temp folder in AppData\Local\Temp, writes that into the textbox, and checks the checkbox. This allows you to quickly try vvvv without any cached packages.

> Source packages
Use repos isn't necessary anymore as you can quickly uncheck the individual repositories.

> Editable packages
Compile source packages isn't necessary anymore as you can quickly uncheck the editable packages. Often only one or two are checked - those that you currently work on.

[x] Package compiler may cache is greyed out if the [ ] Package compiler is turned off. Both boolean flags could be substituted by an enum with 3 entries, but maybe it's even more cryptic than having two checkboxes.

---

Meta: Do we want a new UI / Is this necessary?

I think we might gain clarity, but I also liked the launch Tab as it is now, just by the fact that I can tell a new user: Normally you just don't check anything. With my sketch above I got rid of the one or other negation meaning that also some of those checkboxes would be on by default. And ordering by topic means that sometimes you need to search a bit longer for the option to not load source packages...

Technical details: The old user settings would be lost most probably if we want to have clean code base. Can we get rid of the Tab-based organization of settings, so that after the next cleanup we can still stick with the model?

[sebescudie]

Hey there, thanks for these and sorry for the late reply :-)

I'm trying to figure out how this could look like and came up with this dummy patch. It's just a rough sketch that gives an idea of how this would eventually look like (wordings and all tbd). The (long) text descriptions are also there to help me reason about this, in the end they should end up in a tooltip.

A few questions though :

• What would the "Package compiler" checkbox do in the Advanced section? How does it play with the Source package directories and Editable packages tabs?
• Could you give more details on the Package compiler may cache option?
• I wonder if we should not keep the editor extensions setting as a negative thing that you have to explicitly enable. This setting could be dangerous : if we use the positive checked by default as you suggested (just Editor Extensions), someone could disable it and forget it, and then wonder why no extensions are working. Whereas if you keep it negative, and need to user to actually click it, it makes it more intentional and "memorable".

Let me know what you think!

Cheers

PS : change the extension of this to .vl, github goes brrrr with those
LauncherProto.txt

[gregsn]

Hey! Thanks a lot!

• If you disable the package compiler all packages (even the CoreLib, even if not listed in source package repositories nor in editable packages..) will get compiled from source. This can make sense if you have a last minute issue in your project and just don't have the time and nerve to do it properly by checking the source repository of VLStandardLibs or any other repo. So this is only used for real dirty hacking the vvvv installation or Nuget package folder or for trying to help us track down a bug real quick. It's not something that you typically do. That's why it's advanced.

• Package compiler may cache is only for debugging caching issues of the package compiler itself. I don't know of any reason to turn that off currently.

• Regarding on/off: It's super tricky. I was just trying to get rid of all negations, but this way you end up with a lot of options ticked by default. Package Compiler (may cache) would both be on by default. The story would be: pretty much everthing is enabled by default. But for debugging purposes you want to simplify the system. Even "Debuggable target code" could get negated and be called "Dense target code" (with a tooltip saying that you typically want to disable it in order to be able to read the target code). This way everything under Advanced would be turned on.

• We could even discuss Mute as being a negation. That way you would end up with a ticked checkbox when adding an item saying: it's enabled. As a library dev with many libraries entered in the editable packages I often only want to enable the one that I am currently working on in order to have decent startup time. So I would need to mute everything else. Also we'd need to explain that muting in the editable packages means something different than muting in the package directories even though both is called mute.

• One thing that came to my mind: since editable packages allows you to use * like so VL.Stride* it could make sense that the main control still is a textinput, but with a button allowing to seclect a folder. This would then just copy the folder name into the textbox still allowing you to edit it.

Completely open in all directions. That was just my train of thought.
Thanks again!

PS: I think it would be cool to also have the Nuget Package folder somewhere and show buttons for all folder related inputs opening an explorer window. In case you forgot those.