Common Settings Page Layout about nyxt HOT 24 OPEN

Yes, you'd have to modify the headings panel architecture to allow for "sticky" panels that are associated with buffers. This is outside of the scope.

Just program it all in HTML only. Do the side tabs design that Thomas has proposed.

from nyxt.

All good with respect of aesthetics.

One very important technical requirement is that users needs to understand how a certain parameter is set. For instance, if the user sets the keyscheme to vi, then it needs to be visible from common-settings. In other words, the state of auto-config.lisp must propagate to common-settings.

from nyxt.

Well, I think that common-settings won't be doing its job properly if you can't see the state of the config it covers. If you have a "button" that sets a parameter, you need to have a reliable indicator as well.

from nyxt.

@aadcg I agree. The radio buttons and checkboxes are pretty good indicators on their own. We just need something like that for the other settings as well. We already put that in the spec for default-modes, but the other buttons need it as well.

@aartaka's suggestion is interesting. I'm not sure if it's a direct solution for the issue, but it might help. Still, some settings lend themselves very well to a prompt-buffer with an appropriate source. Set new buffer URL can be similar to set-url and Set default modes can be similar to toggle-modes, for example. As long as we don't lose that, I'm all for using forms. It would be good to avoid writing to file each time the user clicks a radio button.

from nyxt.

Re-iterating for the sake of clarity: if a parameter's default is tomato and the user as sets it to potato, then the next time they go to common-setting they need a UI indication that it's set to potato. In short, a graphical config facility needs to both set and get parameters. An indication of the default value would be a plus too.

from nyxt.

One very important technical requirement is that users needs to understand how a certain parameter is set. For instance, if the user sets the keyscheme to vi, then it needs to be visible from common-settings. In other words, the state of auto-config.lisp must propagate to common-settings.

@aadcg
I totally agree with this requirement, I think we all do. -- my thinking is that the Radio / Checkbox satisfies it nicely for the first few sections.

Then we have a feild to show active modes for the New Buffer Settings section

from nyxt.

@lansingthomas the question is not how to do it, but rather how to integrate it with existing facilities and practices. Let's focus on getting a prototype as soon as possible, and avoid getting distracted with minor issues that we can addressed later.

from nyxt.

Yes, we've been thinking of a good way to show the "current state" of a setting.
Is your idea to show the relevant part of the auto-config file in common-settings? I haven't considered that, but it could be a good solution.
Otherwise, we could show the current value (which is kind of obvious for browser slots, less so for buffer slots). The only catch is that it will require a restart to update the value, until #3120 is finished.

from nyxt.

from nyxt.

Plaintext for copypasta:

Note that some settings may require restarting Nyxt to take effect.

The default keybinding scheme is always present, and CUA bindings will be familiar to many users.

For individual buffers - keyschemes can be toggled with the (toggle-modes) command.

For a persistent keyscheme each time you start Nyxt - make a selection here.

Themes for the browser interface, panel buffers, and internal Nyxt pages like manual, bindings, and common settings.

Select Default Web to view webpages as they are designed.

Select Darkened Web to have Nyxt darken arbitrary webpages you visit, by default.

To darken an individual webpage, use the command (dark-mode).

Incremental changes advised.

Choose your homepage. By default your homepage is set to the internal Nyxt page (nyxt:new)

Choose your starting point when launching Nyxt.

Specify default modes for all new buffers.

This list shows modes for all new buffers. To set modes for individual buffers, use the (toggle-modes) command, or a specific command like (toggle-no-script-mode).

from nyxt.

Let's avoid the Save Settings button if we possibly can.

IF we must do it, we can do it by section, with color changes to show states;

like this draft -

from nyxt.

#3178 might help some of our problems here.

from nyxt.

@lansingthomas How do we feel about being able to collapse/expand each section? We talked about doing that for some specific settings, but maybe it would work well for the whole page? We can use :nsection, like we do in the manual or tutorial.

It would look like this:

from nyxt.

from nyxt.

Yeeeeeeeeeeah, I think this layout is better than the previous (above).

1. compartmentalizes the sections (easier decision making for users)
2. rhymes with settings pages from many other applications (consistent with expectations)
3. accommodates more settings later on (as complexity increases)

side tabs:

what do you all think?

@aartaka

• Design 1 - one long page to paginate
• Design 2 - side tabs
• I don't care just pick something.

@hgluka

• Design 1 - one long page to paginate
• Design 2 - side tabs
• I don't care just pick something.

@aadcg

• Design 1 - one long page to paginate
• Design 2 - side tabs
• I don't care just pick something.

@jmercouris

• Design 1 - one long page to paginate
• Design 2 - side tabs
• I don't care just pick something.

from nyxt.

How do we feel about being able to collapse/expand each section? We talked about doing that for some specific settings, but maybe it would work well for the whole page?

Luka and I spoke on video today, but I will post here in the spirit of transparency.

We decided NOT to do :nsection dropdowns -- it sort of hides things on a page where we want users to have a sense of complete understanding (like they can see ALL options). We also talked about how our dropdowns currently are not very good at communicating state. The triangles look pretty similar open and closed.

from nyxt.

colors for design 2

from nyxt.

@hgluka I think the easiest way to implement it would be to call headings-panel when common-settings is invoked. I think it's ok to list all settings in one page instead of showing the content of one heading and hiding the content of all others.

from nyxt.

Weaving into the headings-panel/side tags discussion: we kind of expose the heading search functionality in the manual, so why not expose it in settings too? That'll remove the need for table of contents or side tabs, and make all the interface closer to other ones (as @hgluka said).

Slightly off-topic: maybe we should make a status buffer button for headings panel/command? It's too useful to be unseen.

from nyxt.

Regarding the implementation (in part responding to @aadcg): I still dislike the intrusive single-letter bindings in the manual and the idea of forcing the panels seems too much to me, but still, I agree with the idea of making Nyxt productivity tools exposed and useful. So I'm on the side of re-using what we already have. That'll also simplify the layout.

from nyxt.

https://www.w3schools.com/howto/howto_js_vertical_tabs.asp

from nyxt.

I'm still leaning towards side-tabs of some kind. There's value in showing the user only one, relevant section.
We even have an open issue for paginating the manual in a similar way: #1541. The side-tab layout here would probably be simpler than a full-blown info-mode equivalent, but the philosophy is the same.

As far as the implementation goes, the headings panel was also my first idea, but it might be too cumbersome for this use case. It stays open even when you switch the main buffer, it shows all headings regardless of level, etc.

from nyxt.

Update: Luka and Tom met today -- here are the actionable items.

@hgluka

• programmatically insert the f1-s documentation for the description column. For sections: {theme, dark mode, default zoom, default URL, restore-session}
• build the edit-user-files button
• add a checkbox item: default cookie policy slot | (in security section)
• build the side panel UI

@lansingthomas

• enlist some poor soul to review and re-write the f1-s documentation for {theme, dark mode, default zoom, default URL, restore-session}

from nyxt.

We also decided to allow special descriptions (written for the common settings page specifically, very human readable) for the other headings/subheadings:

1. Keybindings
2. modes
3. blocker mode
4. no script mode
5. reduce tracking modes

from nyxt.