Reintroduce basicPreferences

[megoth]

Tim introduced a new global dashboard pane called basicPreferences. This didn't quite work before our latest release, so we decided to remove it from the list of global dashboard panes and add it back later.

This issue is about adding it back, and fixing configurations that Tim added earlier (ask him about the specifics of this).

[Vinnl]

@timbl could you link to the earlier version of your work on this?

[megoth]

Tim Introducing basicPreferences - 1273f70
Me moving it to TypeScript - 53164c9
Me removing it from list of global dashboard panes - e9ace09

[Vinnl]

Thanks. And what did not quite work about it earlier?

fixing configurations that Tim added earlier (ask him about the specifics of this).

@timbl, do you have specifics on this? :)

[Vinnl]

And some other questions about the current code that someone could hopefully shed a light on:

• Why are there .source.ts files, and regular .ts files that merely re-export them?
• The hardcoded Turtle string that's in preferencesFormText - is that ShACL? Does the Data Browser already have a form generator? (I believe @megoth mentioned in the past that he thought there wasn't, but there is UI.widgets.appendForm of which it's unclear what exactly it does or how it works.)
• Why is there a reference to https://solid.github.io/solid-panes/dashboard/basicPreferencesForm.ttl#this, which is 404'ing for me? Is that supposed to be referring to a file in the user's Pod?
• And to add the earlier questions: what is currently not quite working in this Pane?
• What configurations did @timbl add earlier, and what needs to be fixed about them?

[timbl]

All I thought I added was a form with two checkboxes, one for "I am a developer" and one "I am a power user".

The inline form should be in a back-quoted ecmascript multiline string for readability, not an escaped single line string.

The only other thing I may have added was chat preferences, like whether you like your chat images expanded inline and so on.

Don't worry about the 404 for the form ... the URI of the form is more or less arbitrary ... as the form is actually included with the JS code. It is parsed inline.

[timbl]

The source is now dashboard/basicPreferences.source.ts because ofa way of solving import incompatibility between nodejs and TS

[timbl]

• Why are there .source.ts files, and regular .ts files that merely re-export them?

Because the nodejs and ES people did not end up making Default Export compatible at runtime, and Arne wanted to use default export for panes.

• The hardcoded Turtle string that's in preferencesFormText - is that ShACL?

No, it is data browser UI Ontology Form Language.

• Does the Data Browser already have a form generator?

Yes... you need to know about it. It is an easy tool for generating panes etc.
(I believe @megoth mentioned in the past that he thought there wasn't, but there is UI.widgets.appendForm of which it's unclear what exactly it does or how it works.)

• Why is there a reference to https://solid.github.io/solid-panes/dashboard/basicPreferencesForm.ttl#this, which is 404'ing for me? Is that supposed to be referring to a file in the user's Pod?

It is a a URI I made up for a constant form. In fact we don't load it run time, so the URI could be anything. I suggest replacing that constant URL with a constant urn:uuid:___ URI instead.

• And to add the earlier questions: what is currently not quite working in this Pane?

Not sure .. have to link it back in and try it.

• What configurations did @timbl add earlier, and what needs to be fixed about them?

I put in: checkboxes for being a developer and/or a poer user, and some
What needs to be fixed, is the form needs to be cleaned up to have a heading for the chat-related stuff. I think it also needs the trusted applications stuff added on the end.

Medium term, this should more or less everything we have been talking about in an Advanced heading, and a Basic heading things like languages I prefer. If you can find a good list of language codes we can import, that would be good for accessibility.

[timbl]

The form system is nice, as it is simple and powerful. A form is a simple bit of recursive RDF defining a form. The implementation in solid-ui is a simple recursive bit of JS which renders a form. The form elements each know which bit of the linked data web is their state. There is a form for editing forms. It would be great at some point to have a parallel implementation based on React components, so different systems could re-use the same forms.

[timbl]

• The Ontology: https://www.w3.org/ns/ui.n3 especially #Form and #FormForm
• The code: https://github.com/solid/solid-ui/blob/master/src/widgets/index.js#L583

[timbl]

Sorry about the lack of documentation!

[timbl]

A field which classifies something like a user into different subclasses is used like
a ui:Classifier; ui:property r:type; ui:category ui:Form] un the FormForm.
so we would want something like
a ui:Classifier; ui:property r:type; ui:category solid:User] where er had also
solid:User a rdfs:Class. solid:PowerUser rsfs:subclassOf solid:User . solid:Developer rsfs:subclassOf solid:User or words to that effect

[Vinnl]

For reference, this is the current state:

(Edit: Well, that was the state with an old version of solid-ui. I've now updated it to master, and now I see an empty white area...)

So I think what needs to be done to close this issue, although I'm not sure how that's different from #145 (maybe @megoth can clarify), is:

• Rename "Color user input by user" to "I am a Power User"
• Rename "Expand image URLs inline" to "I am a Developer" (so this means that a user can be both)
• Fix the PATCH request that is sent to the user's profile to also work when the Power User
• Use a UUID instead of a non-existent and GitHub-hosted URL to identify the preferences form

[megoth]

• Use a UUID instead of a non-existent and GitHub-hosted URL to identify the preferences form

Uncertain about this last one, but apart from that you're correct.

I also read Tim that we should include trustedApps in the basicPreferences (and to remove the standalone tab that is has now, I would assume).

Last, we need to make the checkboxes for Developer and Power User mode have an actual effect (i.e. add developer: true and/or powerUser: true to the corresponding panes and extend the current functionality to display these based on the settings of the user).

[megoth]

Last, we need to make the checkboxes for Developer and Power User mode have an actual effect (i.e. add developer: true and/or powerUser: true to the corresponding panes and extend the current functionality to display these based on the settings of the user).

This one might be a big task, so we might want to split into a separate issue.

[Vinnl]

Use a UUID instead of a non-existent and GitHub-hosted URL to identify the preferences form
Uncertain about this last one, but apart from that you're correct.

Did I then misunderstand what @timbl said?

It is a a URI I made up for a constant form. In fact we don't load it run time, so the URI could be anything. I suggest replacing that constant URL with a constant urn:uuid:___ URI instead.

I also read Tim that we should include trustedApps in the basicPreferences (and to remove the standalone tab that is has now, I would assume).

Yes, but that is #151.

Last, we need to make the checkboxes for Developer and Power User mode have an actual effect (i.e. add developer: true and/or powerUser: true to the corresponding panes and extend the current functionality to display these based on the settings of the user).

Given that that's not mentioned in #145, I presumed that that would certainly be out of scope for this Issue.

[megoth]

From @timbl: these settings should be saved in your private settings

[Vinnl]

Wait, what? What are private settings? In my profile on inrupt.net I only see

    sp:preferencesFile </settings/prefs.ttl>;

Nothing explicitly private or public about them?

[megoth]

Wait, what? What are private settings? In my profile on inrupt.net I only see

    sp:preferencesFile </settings/prefs.ttl>;

Nothing explicitly private or public about them?

True, but if you check the ACL-resource for the file, you'll see that it's private (i.e. only you have access to it) by default.

[Vinnl]

Ah right, so there are no public preferences? Good, I wouldn't know where else to save them other than in the preferencesFile.

[megoth]

Ah right, so there are no public preferences? Good, I wouldn't know where else to save them other than in the preferencesFile.

Yes, there are no public preferences by default (a user could of course make their preferences public, if they want).

[Vinnl]

@timbl What's the status on this? I see there's a new commit by you to this branch, but that doesn't seem to work yet on my side...