Add configuration editing like Firefox's 3.6x about:config

[Jerry]

PROBLEM:

• The growing number of configuration properties is cluttering the GUI dialog panels, making it harder to find and edit the settings relevant to what you need. Many properties are either for advanced power-users or need only typically be set once and never changed again; their presence in the configuration dialogs only adds to the clutter. A more scalable approach is required.
• Need more comprehensive and detailed descriptions, usage, caveats, etc. about each property.
• Need a way to search for properties, not only by name but also by matching text in their associated descriptions.
• Direct user-editing of the configuration file is problematic, especially with so many options, and should be proscribed completely.

PROPOSED SOLUTION:

• Keep only the most important, commonly used and co-dependent properties in explicit dialog panels. For each functional category, a single Advanced button or link can take the user, not to another more cluttered dialog, but into a predefined search on all other properties relevant to that category using the tabular UI proposed below.
• For all properties, including tweaks, provide a simple, scrollable, tabular UI similar to the about:config interface in Firefox 3.6x, but augmented with detailed descriptions. This allows the application to maintain complete control over the configuration file access, insuring property data has the right format or enumerated value, while also helping the user to set the right property, properly. Tweaks and other experimental properties can be visually rendered appropriately to indicate their status. The help descriptions can appear in summarized form as an additional column in the table, but the more detailed explanation, even the verbatim contents of the relevant History log entry, should only be a click away.
• Rename the properties to conform to the hierarchical naming convention used by Firefox (which goes back many years to X-Window). This format enables properties to be self-categorizing and to a large extent, self-descriptive. To facilitate this and searching, avoid abbreviations and acronyms in property names. Ideally, abandon the ancient and limited Windows INI format or provide a suitable adapter layer. Regardless, users should never have to access this file directly.
• As done in Firefox's about:config, add a search/filter area where users can search on property name and description text so that only matching properties are listed.

[admin]

I started thinking about Configuration.

In (my) theory the Configuration dialog should contain only set-and-forget settings. And the preset factory defaults for all these settings should be good for most of the users.

Therefore I want to ask you: Are you using Configuration (F9) regularly to change some settings? If yes, which settings are these?

[Jerry]

In (my) theory the Configuration dialog should contain only set-and-forget settings. And the preset factory defaults for all these settings should be good for most of the users. Therefore I want to ask you: Are you using Configuration (F9) regularly to change some settings? If yes, which settings are these?

I'll let others respond about what settings they regularly change in the configuration dialog. I usually don't change anything once I set things up, unless a new option comes along. For me, personally, the key issue is being able to see all the properties, including tweaks, in a Firefox-like tabular editing mode with filtering, hierarchical naming and descriptions, so that one never has to go directly into the internal file, advanced properties are easily discovered, etc. This is in addition to the configuration dialog, about which there seems to be a lot of debate about what and should be there -- I have less interest in that debate, other than offering the view I expressed in my original post.

[PeterH]

Do I understand you correct?

If I, after a new installation, want to set "Don't save on Exit" without editing the config file, I have to change it regularly?

Sorry: this is how your question sounds to me.

[admin]

Do I understand you correct?

If I, after a new installation, want to set "Don't save on Exit" without editing the config file, I have to change it regularly?

Sorry: this is how your question sounds to me.

No no, that's not what I meant.

I just want to know if you are frequently using the configuration dialog to change something.

[PeterH]

Do I understand you correct?

If I, after a new installation, want to set "Don't save on Exit" without editing the config file, I have to change it regularly?

Sorry: this is how your question sounds to me.

No no, that's not what I meant.

I just want to know if you are frequently using the configuration dialog to change something.

...but that's what I meant. I don't think configuration should be difficult if I don't use it frequently.
As long as I understand an option correct, I will only change it once...

Maybe you could ask people how many options they had changed - but not how often, I think!

[j_c_hallgren]

In (my) theory the Configuration dialog should contain only set-and-forget settings. And the preset factory defaults for all these settings should be good for most of the users. Therefore I want to ask you: Are you using Configuration (F9) regularly to change some settings? If yes, which settings are these?

I'll let others respond about what settings they regularly change in the configuration dialog. I usually don't change anything once I set things up, unless a new option comes along. For me, personally, the key issue is being able to see all the properties, including tweaks, in a Firefox-like tabular editing mode with filtering, hierarchical naming and descriptions, so that one never has to go directly into the internal file, advanced properties are easily discovered, etc.

Agreeing with Jerry here! There are some settings in config that I tried various settings for a while until I found the one I wanted but I can't recall when I last changed things via Config...however, on occasion, I've temporarily set a couple of settings to other values when I doing a particular task and then revert them back so having those easily found helps...but if they were avail via FF style, that would still be highly preferred over having it only via INI edit.

[admin]

No, I think we are going in circles now. I will not elevate tweaks to any FF style list, nor will I do an FF style list for anything else. I would probably waste 3 months on this, for a very small gain.

What I'm thinking about was inspired by this:

Keep only the most important, commonly used and co-dependent properties in explicit dialog panels.

If a small set of settings could be identified that most of the users tend to change (once or regularly), then I would think about adding an additional dialog for the most-used settings (and maybe call the current one "Extended Settings").

[PeterH]

If a small set of settings could be identified that most of the users tend to change (once or regularly), then I would think about adding an additional dialog for the most-used settings (and maybe call the current one "Extended Settings").

From my point of view this description makes sense.

But it's true: the problem will be to identify those "more used" settings. I don't think by often changing options, but by option that are changed by many users.

To tell the truth: as long as the current settings dialog remains, under what name you wish, I'm not much concerned.
(But maybe a new dialog convinces me so much that I'll use it?)

[nas8e9]

My $0.02 would be to keep the current dialog but add a search facility to it. Somewhat awkwardly, Directory Opus actually has a nice implementation, but so do UltraEdit and Visual Studio.

This way, the categorisation problem (settings make sense in more than one UI context/section, making a strict tree structure awkward) as well as discoverability are improved: e.g., people type in "rename", with results coming from both General > Renaming, as well as Custom Copy.

An added bonus is that it doesn't make big documentation changes necessary, and dialog boxes with built-in search are already a familiar part of XYplorer's UI.

[admin]

My $0.02 would be to keep the current dialog but add a search facility to it. Somewhat awkwardly, Directory Opus actually has a nice implementation, but so do UltraEdit and Visual Studio.

This way, the categorisation problem (settings make sense in more than one UI context/section, making a strict tree structure awkward) as well as discoverability are improved: e.g., people type in "rename", with results coming from both General > Renaming, as well as Custom Copy.

An added bonus is that it doesn't make big documentation changes necessary, and dialog boxes with built-in search are already a familiar part of XYplorer's UI.

Agreed, this would work (as opposed to FF's tree structure which does not). Would still be some work for me, but not beyond possibility. Lo prio however, end of road map.

[Jerry]

... settings make sense in more than one UI context/section, making a strict tree structure awkward)

What are examples of actual settings that apply to more than one UI context/section ?

[nas8e9]

... settings make sense in more than one UI context/section, making a strict tree structure awkward)

What are examples of actual settings that apply to more than one UI context/section ?

I mentioned in my original post rename settings. Some other examples are History per tab (applying to both History and Tabs) and settings pertaining to the network (several sections).

[Jerry]

... settings make sense in more than one UI context/section, making a strict tree structure awkward)

What are examples of actual settings that apply to more than one UI context/section ?

I mentioned in my original post rename settings. Some other examples are History per tab (applying to both History and Tabs) and settings pertaining to the network (several sections).

I'm sorry, I really don't see the problem. This kind of property naming convention has been used successfully for many years. For tab history, you name the property with history.tab or tab.history so a query on either tab or history will match. The naming convention may not always strictly follow the dialog, nor should it have to. But I would submit to you that if there are so many instances of properties pertaining to more than 1 section of the dialogs, there's probably a flaw in the design of the dialogs or in the use of the property. This is one reason why the dialogs alone are getting problematic with so many properties.

I know I made my proposal clear enough so I won't spend energy on further argument. Also, I'm beginning to realize from this and other discussions that perspectives among many in the forum here about how to do software, both from a design and implementation, differs fundamentally from mine, and I'm guessing it's due to our different professional experiences.

[nas8e9]

I'm sorry, I really don't see the problem. This kind of property naming convention has been used successfully for many years. For tab history, you name the property with history.tab or tab.history so a query on either tab or history will match. The naming convention may not always strictly follow the dialog, nor should it have to. But I would submit to you that if there are so many instances of properties pertaining to more than 1 section of the dialogs, there's probably a flaw in the design of the dialogs or in the use of the property. This is one reason why the dialogs alone are getting problematic with so many properties.

I know I made my proposal clear enough so I won't spend energy on further argument. Also, I'm beginning to realize from this and other discussions that perspectives among many in the forum here about how to do software, both from a design and implementation, differs fundamentally from mine, and I'm guessing it's due to our different professional experiences.

I can claim exactly no professional software development experience, which may or may not disqualify me from offering an opinion.

This discussion, triggered by zer0's unhappiness with adding yet another option to an already large dialog, has been very messy, particularly with regard to tweaks. I won't rehash that discussion either, but in the end the developer has to be persuaded that there is a problem to begin with. All feedback has been somewhat theoretical as well as generic in the sense that all powerful software grow options and with XYplorer's development pace, at an alarming rate. How to deal with this, has seen relatively little consensus.

I hope we can agree that shipping is a feature, and thus pragmatism is called for. That's not *our* job however: neither planning nor choosing, implementing nor deciding what and when to ship. From Don's posts I get the impression that he's hitting limits with regard to options and further tweaks, and is aware that the current dialog won't quite scale in all respects. Since your proposal includes searching as well, I take it you don't object to adding that to the existing functionality, but would like a different approach in addition to and underlying the current settings infrastructure. Don doesn't see more than marginal return on that, especially when compared to the functionality he still plans to add.

On a personal note, it's always a pity to see new users raving about XYplorer and its developer, only for them to discover that both have limits, and then sometimes slide towards ranting. This is still the same software you tried and liked enough to buy, with the same amazing developer at the helm. It's just that nothing and no one is unlimited or, well, perfect.

Edited.