Hi, all,
What do you think about creating a firefox-about:config-like interface for the hidden preferences? For example, a "Various" tab in the preferences dialog, with a "name value" list, a check button or a text entry (depending on the currenttly selected element), and a link to www.geany.org/manual/current/#hidden-preferences.
That'll take some time to write, for example to check that all changes are applied immediately, but I'm willing to do it, if you think it's a good idea. The stash provides a good base for such an interface.
On Tue, Oct 19, 2010 at 6:01 PM, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
Hi, all,
What do you think about creating a firefox-about:config-like interface for the hidden preferences? For example, a "Various" tab in the preferences dialog, with a "name value" list, a check button or a text entry (depending on the currenttly selected element), and a link to www.geany.org/manual/current/#hidden-preferences.
That'll take some time to write, for example to check that all changes are applied immediately, but I'm willing to do it, if you think it's a good idea. The stash provides a good base for such an interface.
Personally I like it. But it's probably the maintainer's take that counts. Regards Liviu
-- E-gards: Jimmy _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Tue, 19 Oct 2010 19:01:10 +0300 Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
What do you think about creating a firefox-about:config-like interface for the hidden preferences? For example, a "Various" tab in the preferences dialog, with a "name value" list, a check button or a text entry (depending on the currenttly selected element), and a link to www.geany.org/manual/current/#hidden-preferences.
That'll take some time to write, for example to check that all changes are applied immediately, but I'm willing to do it, if you think it's a good idea. The stash provides a good base for such an interface.
It would be nice for the user. However, it would mean all hidden prefs would need to be made reloadable. I don't want to do that really.
The feature could still be implemented, but require that the user restart after editing a setting. An info area could be shown reminding the user to restart.
Perhaps the feature should be implemented as a plugin, but could be shipped with Geany.
Nick
On Tue, 19 Oct 2010 17:46:23 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
On Tue, 19 Oct 2010 19:01:10 +0300 Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
What do you think about creating a firefox-about:config-like interface for the hidden preferences? For example, a "Various" tab in the preferences dialog, with a "name value" list, a check button or a text entry (depending on the currenttly selected element), and a link to www.geany.org/manual/current/#hidden-preferences.
That'll take some time to write, for example to check that all changes are applied immediately, but I'm willing to do it, if you think it's a good idea. The stash provides a good base for such an interface.
It would be nice for the user. However, it would mean all hidden prefs would need to be made reloadable. I don't want to do that really.
Yes... Some settings will probabbly work automatically, for example editor ones, and others may be easily reloadable, but I too don't want deep changes just to make _all_ prefs "appliable".
The feature could still be implemented, but require that the user restart after editing a setting. An info area could be shown reminding the user to restart.
Quite reasonable, IMHO.
Perhaps the feature should be implemented as a plugin, but could be shipped with Geany.
A plugin implies that the hidden prefs will both be visually editable and retain their "hidden" status... Having it both ways seems confusing to me, not simpler.
Such a plugin will either have to include it's own list all hidden prefs, synced with Geany, or rely on specially exported functions, useful only for this particular plugin. A tab in the Preferences dialog, OTOH, is much more straightforward to implement.
On Tue, 19 Oct 2010 21:00:40 +0300 Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
What do you think about creating a firefox-about:config-like interface for the hidden preferences? For example, a "Various" tab in the preferences dialog, with a "name value" list, a check button or a text entry (depending on the currenttly selected element), and a link to www.geany.org/manual/current/#hidden-preferences.
That'll take some time to write, for example to check that all changes are applied immediately, but I'm willing to do it, if you think it's a good idea. The stash provides a good base for such an interface.
It would be nice for the user. However, it would mean all hidden prefs would need to be made reloadable. I don't want to do that really.
Yes... Some settings will probabbly work automatically, for example editor ones, and others may be easily reloadable, but I too don't want deep changes just to make _all_ prefs "appliable".
You're right, perhaps we could separate hidden prefs that need restarting and those that don't.
The feature could still be implemented, but require that the user restart after editing a setting. An info area could be shown reminding the user to restart.
Quite reasonable, IMHO.
Perhaps the feature should be implemented as a plugin, but could be shipped with Geany.
A plugin implies that the hidden prefs will both be visually editable and retain their "hidden" status... Having it both ways seems confusing to me, not simpler.
Such a plugin will either have to include it's own list all hidden prefs, synced with Geany, or rely on specially exported functions, useful only for this particular plugin. A tab in the Preferences dialog, OTOH, is much more straightforward to implement.
OK, perhaps it's better not to export the stash groups, and the work will require changes/additions to Stash anyway. So core support might be OK.
Nick
On 20 October 2010 22:25, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Tue, 19 Oct 2010 21:00:40 +0300 Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
What do you think about creating a firefox-about:config-like interface for the hidden preferences? For example, a "Various" tab in the preferences dialog, with a "name value" list, a check button or a text entry (depending on the currenttly selected element), and a link to www.geany.org/manual/current/#hidden-preferences.
That'll take some time to write, for example to check that all changes are applied immediately, but I'm willing to do it, if you think it's a good idea. The stash provides a good base for such an interface.
It would be nice for the user. However, it would mean all hidden prefs would need to be made reloadable. I don't want to do that really.
I also think this UI would be nice to have.
Yes... Some settings will probabbly work automatically, for example editor ones, and others may be easily reloadable, but I too don't want deep changes just to make _all_ prefs "appliable".
You're right, perhaps we could separate hidden prefs that need restarting and those that don't.
Have two sections of the editor (or separate into two tabs), one for prefs that don't need restart and one for those that do with appropriate warning. Of course that needs to have that attribute associated with the preference some how.
Cheers Lex
The feature could still be implemented, but require that the user restart after editing a setting. An info area could be shown reminding the user to restart.
Quite reasonable, IMHO.
Perhaps the feature should be implemented as a plugin, but could be shipped with Geany.
A plugin implies that the hidden prefs will both be visually editable and retain their "hidden" status... Having it both ways seems confusing to me, not simpler.
Such a plugin will either have to include it's own list all hidden prefs, synced with Geany, or rely on specially exported functions, useful only for this particular plugin. A tab in the Preferences dialog, OTOH, is much more straightforward to implement.
OK, perhaps it's better not to export the stash groups, and the work will require changes/additions to Stash anyway. So core support might be OK.
Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Wed, 20 Oct 2010 12:25:46 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
That'll take some time to write, for example to check that all changes are applied immediately, but I'm willing to do it, if you think it's a good idea. The stash provides a good base for such an interface.
It would be nice for the user. However, it would mean all hidden prefs would need to be made reloadable. I don't want to do that really.
Yes... Some settings will probabbly work automatically, for example editor ones, and others may be easily reloadable, but I too don't want deep changes just to make _all_ prefs "appliable".
You're right, perhaps we could separate hidden prefs that need restarting and those that don't.
Here I meant having two hidden pref stash groups, one for prefs requiring restart and one not. keyfile.h could expose them so other files can use them.
I wasn't thinking about visually separating the prefs. Perhaps this could be done by having 2 different treeview parent items, rather than having to switch tabs (as Lex suggests). That way the user can see all hidden prefs on screen at once. But visually separating 'restart' prefs is a refinement of the feature and could be done later.
Also, I think the feature code should be in a separate file, not prefs.c.
Nick
On Wed, 20 Oct 2010 12:25:46 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
On Tue, 19 Oct 2010 21:00:40 +0300 Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
Yes... Some settings will probabbly work automatically, for example editor ones, and others may be easily reloadable, but I too don't want deep changes just to make _all_ prefs "appliable".
You're right, perhaps we could separate hidden prefs that need restarting and those that don't.
On Thu, 21 Oct 2010 09:56:27 +1100 Lex Trotman elextr@gmail.com wrote:
Have two sections of the editor (or separate into two tabs), one for prefs that don't need restart and one for those that do with appropriate warning. Of course that needs to have that attribute associated with the preference some how.
On Wed, 20 Oct 2010 12:25:46 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
I wasn't thinking about visually separating the prefs. Perhaps this could be done by having 2 different treeview parent items, rather than having to switch tabs (as Lex suggests). That way the user can see all hidden prefs on screen at once.
I think a "You need to restart Geany for this setting to take effect" in the editing/infomration area below the list will suffice. Using the x11 SM reverse option parsing, even a "Restart Now" button can be written. :) But all that's secondary.
There isn't much entusiasm about $subject, but at least nobody is against the idea. So I'll give it a try this weekend.
On Thu, 21 Oct 2010 18:58:43 +0300 Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
I wasn't thinking about visually separating the prefs. Perhaps this could be done by having 2 different treeview parent items, rather than having to switch tabs (as Lex suggests). That way the user can see all hidden prefs on screen at once.
I think a "You need to restart Geany for this setting to take effect" in the editing/infomration area below the list will suffice. Using
Yes, let's keep it simple.
the x11 SM reverse option parsing, even a "Restart Now" button can be written. :) But all that's secondary.
There isn't much entusiasm about $subject, but at least nobody is against the idea. So I'll give it a try this weekend.
I like the idea.
Nick
On 22 October 2010 03:10, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Thu, 21 Oct 2010 18:58:43 +0300 Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
I wasn't thinking about visually separating the prefs. Perhaps this could be done by having 2 different treeview parent items, rather than having to switch tabs (as Lex suggests). That way the user can see all hidden prefs on screen at once.
I think a "You need to restart Geany for this setting to take effect" in the editing/infomration area below the list will suffice. Using
Yes, let's keep it simple.
Sure, requiring a restart for all of them is safe.
the x11 SM reverse option parsing, even a "Restart Now" button can be written. :) But all that's secondary.
There isn't much entusiasm about $subject, but at least nobody is against the idea. So I'll give it a try this weekend.
Of course the "problem" that is likely to generate the most heat is what to call these prefs :-D, they can't continue to be called "hidden" as they are now visible in a GUI.
Since these are meant to be rarely used preferences I'd suggest the name needs to reflect that, so also justifying them being separate from other preferences on the same topic, otherwise there will be continual suggestions that they be moved to be with the other preferences on that topic.
So to start the ball rolling, I'll suggest "extra" or additional" as the tab labels and "Extra/Additional rarely used preferences" as a bold title on the tab and the documentation. Let the disagreements start :-)
Cheers Lex
I like the idea.
Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Le 22/10/2010 01:44, Lex Trotman a écrit :
On 22 October 2010 03:10, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Thu, 21 Oct 2010 18:58:43 +0300 Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
I wasn't thinking about visually separating the prefs. Perhaps this could be done by having 2 different treeview parent items, rather than having to switch tabs (as Lex suggests). That way the user can see all hidden prefs on screen at once.
I think a "You need to restart Geany for this setting to take effect" in the editing/infomration area below the list will suffice. Using
Yes, let's keep it simple.
Sure, requiring a restart for all of them is safe.
the x11 SM reverse option parsing, even a "Restart Now" button can be written. :) But all that's secondary.
There isn't much entusiasm about $subject, but at least nobody is against the idea. So I'll give it a try this weekend.
I personally like the idea :) Can I suggest a Filter entry to filter the displayed entries by name for easier search? :D
Of course the "problem" that is likely to generate the most heat is what to call these prefs :-D, they can't continue to be called "hidden" as they are now visible in a GUI.
Since these are meant to be rarely used preferences I'd suggest the name needs to reflect that, so also justifying them being separate from other preferences on the same topic, otherwise there will be continual suggestions that they be moved to be with the other preferences on that topic.
So to start the ball rolling, I'll suggest "extra" or additional" as the tab labels and "Extra/Additional rarely used preferences" as a bold title on the tab and the documentation. Let the disagreements start :-)
I'd suggest "Advanced", simply because most applications use this term (Firefox, Gajim, for the one I know they have similar stuff).
BTW, I think this preference editor might integrate not only the hidden prefs but all of them -- like I think FF does. I'd think it's easier to implement, and I think it's probably more intuitive for the one who want to use this, and I don't see any reason why it would be worst. Anyway, it's for those who want to do tricky things.
Regards, Colomban
On Fri, 22 Oct 2010 02:04:07 +0200 Colomban Wendling lists.ban@herbesfolles.org wrote:
Can I suggest a Filter entry to filter the displayed entries by name for easier search? :D
Maybe this could be added later.
Of course the "problem" that is likely to generate the most heat is what to call these prefs :-D, they can't continue to be called "hidden" as they are now visible in a GUI.
Since these are meant to be rarely used preferences I'd suggest the name needs to reflect that, so also justifying them being separate from other preferences on the same topic, otherwise there will be continual suggestions that they be moved to be with the other preferences on that topic.
So to start the ball rolling, I'll suggest "extra" or additional" as the tab labels and "Extra/Additional rarely used preferences" as a bold title on the tab and the documentation. Let the disagreements start :-)
I'd suggest "Advanced", simply because most applications use this term (Firefox, Gajim, for the one I know they have similar stuff).
Personally I prefer Lex's suggestions, but don't really mind.
BTW, I think this preference editor might integrate not only the hidden prefs but all of them -- like I think FF does. I'd think it's easier to implement, and I think it's probably more intuitive for the one who want to use this, and I don't see any reason why it would be worst. Anyway, it's for those who want to do tricky things.
Actually it would be much harder to implement because all the code to update Geany after a pref is changed would need to be changed.
Currently almost all hidden prefs use Stash, which makes this feature possible. Most Prefs dialog settings don't use it.
Nick
On Fri, 22 Oct 2010 13:34:28 +0100 Nick Treleaven nick.treleaven@btinternet.com wrote:
On Fri, 22 Oct 2010 02:04:07 +0200 Colomban Wendling lists.ban@herbesfolles.org wrote:
Can I suggest a Filter entry to filter the displayed entries by name for easier search? :D
Maybe this could be added later.
They are 20 entries total, and looking at the Keybindings, at least 15 will fit on the first page of the list. IMHO, alphabetical sort would be enough.
While on the topic: Nick, in July I wrote about the msgwin_*_visible preferences. They do not appear in the Preferences dialog, but reside in load_dialog_prefs() and save_dialog_prefs(). You found that Enrico added them, with the intent to write a GUI:
r4500 | eht16 | 2009-12-20 20:07:52 +0000 (Sun, 20 Dec 2009) | 1 line Add preferences for hiding single tabs from the messages window (no GUI preferences yet, still to be implemented).
but never wrote it, and so they are now officially documented as hidden. How about moving them into the hidden group of init_pref_groups()?
On Fri, 22 Oct 2010 19:27:07 +0300 Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
Can I suggest a Filter entry to filter the displayed entries by name for easier search? :D
Maybe this could be added later.
They are 20 entries total, and looking at the Keybindings, at least 15 will fit on the first page of the list. IMHO, alphabetical sort would be enough.
Sure, keep it simple at first. Then we'll see if anything else makes sense. Also it's much easier to review patches if they aren't too ambitious.
While on the topic: Nick, in July I wrote about the msgwin_*_visible preferences. They do not appear in the Preferences dialog, but reside in load_dialog_prefs() and save_dialog_prefs(). You found that Enrico added them, with the intent to write a GUI:
r4500 | eht16 | 2009-12-20 20:07:52 +0000 (Sun, 20 Dec 2009) | 1 line Add preferences for hiding single tabs from the messages window (no GUI preferences yet, still to be implemented).
but never wrote it, and so they are now officially documented as hidden. How about moving them into the hidden group of init_pref_groups()?
Yes, go ahead. I think there may be other hidden prefs that don't use stash too.
Nick
On 23 October 2010 03:39, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Fri, 22 Oct 2010 19:27:07 +0300 Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
Can I suggest a Filter entry to filter the displayed entries by name for easier search? :D
Maybe this could be added later.
They are 20 entries total, and looking at the Keybindings, at least 15 will fit on the first page of the list. IMHO, alphabetical sort would be enough.
Sure, keep it simple at first. Then we'll see if anything else makes sense. Also it's much easier to review patches if they aren't too ambitious.
While on the topic: Nick, in July I wrote about the msgwin_*_visible preferences. They do not appear in the Preferences dialog, but reside in load_dialog_prefs() and save_dialog_prefs(). You found that Enrico added them, with the intent to write a GUI:
r4500 | eht16 | 2009-12-20 20:07:52 +0000 (Sun, 20 Dec 2009) | 1 line Add preferences for hiding single tabs from the messages window (no GUI preferences yet, still to be implemented).
but never wrote it, and so they are now officially documented as hidden. How about moving them into the hidden group of init_pref_groups()?
Yes, go ahead. I think there may be other hidden prefs that don't use stash too.
Unless they have been changed the three hidden build prefs don't use stash.
Cheers Lex
Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On 22 October 2010 11:04, Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 22/10/2010 01:44, Lex Trotman a écrit :
On 22 October 2010 03:10, Nick Treleaven nick.treleaven@btinternet.com wrote:
On Thu, 21 Oct 2010 18:58:43 +0300 Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
I wasn't thinking about visually separating the prefs. Perhaps this could be done by having 2 different treeview parent items, rather than having to switch tabs (as Lex suggests). That way the user can see all hidden prefs on screen at once.
I think a "You need to restart Geany for this setting to take effect" in the editing/infomration area below the list will suffice. Using
Yes, let's keep it simple.
Sure, requiring a restart for all of them is safe.
the x11 SM reverse option parsing, even a "Restart Now" button can be written. :) But all that's secondary.
There isn't much entusiasm about $subject, but at least nobody is against the idea. So I'll give it a try this weekend.
I personally like the idea :) Can I suggest a Filter entry to filter the displayed entries by name for easier search? :D
Of course the "problem" that is likely to generate the most heat is what to call these prefs :-D, they can't continue to be called "hidden" as they are now visible in a GUI.
Since these are meant to be rarely used preferences I'd suggest the name needs to reflect that, so also justifying them being separate from other preferences on the same topic, otherwise there will be continual suggestions that they be moved to be with the other preferences on that topic.
So to start the ball rolling, I'll suggest "extra" or additional" as the tab labels and "Extra/Additional rarely used preferences" as a bold title on the tab and the documentation. Let the disagreements start :-)
I'd suggest "Advanced", simply because most applications use this term (Firefox, Gajim, for the one I know they have similar stuff).
Hi Columban,
The only reason I didn't suggest "advanced" is that Firefox is the only application I know that uses it as a grab bag of miscellaneous things (eg spell check is advanced?). Most of the other tools I use keep advanced options associated with the topic they relate to, using a button or extender on the basic page to navigate to the advanced options. This might be the best UI solution in the long term but its not what we want for now.
Cheers Lex
BTW, I think this preference editor might integrate not only the hidden prefs but all of them -- like I think FF does. I'd think it's easier to implement, and I think it's probably more intuitive for the one who want to use this, and I don't see any reason why it would be worst. Anyway, it's for those who want to do tricky things.
Regards, Colomban _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Le 23/10/2010 02:22, Lex Trotman a écrit :
On 22 October 2010 11:04, Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 22/10/2010 01:44, Lex Trotman a écrit :
[…]
So to start the ball rolling, I'll suggest "extra" or additional" as the tab labels and "Extra/Additional rarely used preferences" as a bold title on the tab and the documentation. Let the disagreements start :-)
I'd suggest "Advanced", simply because most applications use this term (Firefox, Gajim, for the one I know they have similar stuff).
Hi Columban,
The only reason I didn't suggest "advanced" is that Firefox is the only application I know that uses it as a grab bag of miscellaneous things (eg spell check is advanced?). Most of the other tools I use keep advanced options associated with the topic they relate to, using a button or extender on the basic page to navigate to the advanced options. This might be the best UI solution in the long term but its not what we want for now.
Yes, of course this kind of presentation is not the best. But the reason why I think the advanced name isn't that bad is that I see the Firefox-style preference list more as "there's all, do what you want with it" than "this is useful extra stuff". So with the first definition, I think the idea that you need to know what you do before playing with this is correctly suggested with "advanced". (BTW FF adds a button labeled "I'll take care, I promise" or something like that to access this editor :D) But there's probably no such "dangerous" options in Geany, so it doesn't really matter.
But that was only my POV, and without some further info (e.g. not all prefs will appear). Anyway, I don't think my suggestion is the Right Thing(tm), just my feeling ;) If you all prefer "additional", why not.
Cheers, Colomban
On 23 October 2010 12:06, Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 23/10/2010 02:22, Lex Trotman a écrit :
On 22 October 2010 11:04, Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 22/10/2010 01:44, Lex Trotman a écrit :
[…]
So to start the ball rolling, I'll suggest "extra" or additional" as the tab labels and "Extra/Additional rarely used preferences" as a bold title on the tab and the documentation. Let the disagreements start :-)
I'd suggest "Advanced", simply because most applications use this term (Firefox, Gajim, for the one I know they have similar stuff).
Hi Columban,
The only reason I didn't suggest "advanced" is that Firefox is the only application I know that uses it as a grab bag of miscellaneous things (eg spell check is advanced?). Most of the other tools I use keep advanced options associated with the topic they relate to, using a button or extender on the basic page to navigate to the advanced options. This might be the best UI solution in the long term but its not what we want for now.
Yes, of course this kind of presentation is not the best. But the reason why I think the advanced name isn't that bad is that I see the Firefox-style preference list more as "there's all, do what you want with it" than "this is useful extra stuff". So with the first definition, I think the idea that you need to know what you do before playing with this is correctly suggested with "advanced". (BTW FF adds a button labeled "I'll take care, I promise" or something like that to access this editor :D)
Ahhh, we are not talking about the same thing!! You are talking about about:config I'm talking about edit->preferences->advanced tab which is more how Ditmar is planning to present his GUI in Geany.
That explains your suggestion to present everything, which didn't make sense otherwise. That is indeed an advanced UI, whereas Ditmars is more an access to just some rarely used and some possibly questionable preferences.
But there's probably no such "dangerous" options in Geany, so it doesn't really matter.
IIRC some were hidden because they interfered with others or didn't work on all platforms or they were non-standard, more confusing than dangerous. And some because the programmer was too lazy to code for changing them (mine) :-)
Cheers Lex
But that was only my POV, and without some further info (e.g. not all prefs will appear). Anyway, I don't think my suggestion is the Right Thing(tm), just my feeling ;) If you all prefer "additional", why not.
Cheers, Colomban _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Hi,
This is a screenshot of the (not yet complete) Various tab.
The main function is:
void stash_setup_treeview(GPtrArray *group_array, gboolean variable, GtkTreeView *tree, GtkLabel *label, GtkContainer *container);
group_array - obvious
variable - display/edit the groups marked as "variable" [write_once] or all.
tree - obvious
label - if not NULL, displays the currently selected setting name.
container - if not NULL, when a setting is selected, an edit widget is created, based on the setting type and inserted into container. If NULL, there is no editing.
Currentry prefs.c calls stash_setup_treeview(pref_groups, TRUE, widgets-obtained-from-the-Preferences-dialog). But we may call it with, say, an array of plugins groups and FALSE. :)
Hunting the VTE/vc usage took me some time, I'll call it a day. Unfortunately, vc requires some fixing.
