[Monodevelop-devel] Per-project styles & policies

Michael Hutchinson m.j.hutchinson at gmail.com
Tue Sep 30 14:18:22 EDT 2008

On Tue, Sep 30, 2008 at 8:30 AM, Lluis Sanchez Gual <lluis at novell.com> wrote:
> El dl 29 de 09 de 2008 a les 16:51 -0400, en/na Michael Hutchinson va
> escriure:
>> Hi everyone,
>> Here are my current thoughts concerning per-project styles and
>> policies, so that we can discuss it before I go ahead and implement
>> it. I also have an number of questions that are interspersed
>> throughout this email.
>> Rationale
>> =======
>> There are a number of settings and preferences in MD that should be
>> customisable for different solutions/projects. Basically, anything
>> that affects the style of the code you write should be able to be set
>> for a particular project, since different projects have different
>> styles and policies. I've lumped "Styles and Policies" together into
>> one heading since I believe they are related.
> Regarding styles, I want to stress that they are "anything that affects
> the style of the code you write", which means that settings such as
> indent mode (auto, smart) are not styles.

Exactly, I should have been clearer. Another example:
* the presence of the column ruler is a user preference
* the /width/ of the column ruler is a per-project setting

>> Text Editor Settings
>> ==============
>> These are the ones that most people care about -- per-mimetype
>> settings for the general text editor behaviour such as tabs-to-spaces,
>> editor width, tab width, standard headers. Some languages may add to
>> this, e.g. C# indenter behaviour, and in future things like
>> auto-formatting.
> Indenter behavior and auto-formatting are not styles, and should not be
> added to project preferences. On the other hand, formatting rules are
> styles.

Yes, sorry for any ambiguity here. I meant the formatting behaviour of
the indenter/auto-formatter.

> About storing styles per-mimetype, I'm not sure this is needed. It makes
> more sense to present styles to the user organized by file type, but at
> a higher level than mime type. For example we could present settings for
> C#, ASP.NET, XML. Those file types could be sub-divided in mime types if
> we really need that level of detail.
>> There should also be a "default" style, and the
>> per-mimetype settings should override this.
>> * Should we allow users to add custom mimetypes for their own file
>> formats, or just support the "major" text/code mimetypes registered in
>> MD?
> I think we should allow binding mime types to file type categories
> (e.g. .addin files to XML category).

Well, that what VS does, kinda -- it lets you bind arbitrary file
extensions to editors, e.g. the C#, XML, XAML editors...

However, if we have a panel to do something like that, it's almost
trivial to allow each kind to have its own style.

>> * Should we list only the mimetypes used in the project?
> We should somehow filter out file types which don't make sense in a
> given project. For example, ASP.NET styles should not be shown in a GTK#
> project (although makes sense to show XML settings in all kind of
> projects).

It won't be very easy. Since styles will mostly be edited at the
solution level, the solution's dialog is going to have to scan all
child projects for file types.

>> * For each mimetype, should there be a checkbox to override the
>> "default" text style? Or should there be a UI for adding/removing text
>> styles to the tree?
> I don't know how you plan to implement the GUI. IMO, style settings
> could be implemented just like other project settings, using option
> panels. By changing a setting you would be overriding it. There could be
> a button for restoring default settings.

Unfortunately that doesn't make the settings cascade behaviour
obvious. I'd prefer to have the user explicitly override the parent
solution's settings.

>> Policies
>> ======
>> There are a number of other per-project settings that aren't quite
>> styles, but also aren't really build options or project properties.
>> I'm calling these "policies" for now. The only existing one is
>> changelog policies; in future, we could add settings such as "pass
>> tests before checkin", "check style before checkin", "must include
>> changelog entry", etc.
> Sounds good.
>> Settings Infrastructure
>> ================
>> Many of these settings may need to be overridable for individual
>> projects within a solution, because a solution's projects may have
>> been imported from elsewhere with different coding style. For this
>> reason, we need an infrastructure that can be used to get the setting
>> for a project, and if the setting has not been overridden, will grab
>> the setting from the parent solution.
>> * How important is this feature?
> I don't think it is important.

You don't think it's important for project to be able to override
solution-level settings? I've spoken with a few people who disagree --
the main use case seems to have been importe

>> * How many of the settings really need to be overridable at project level?
> I don't see why there should be a restriction on that.

Well, if there are settings that nobody ever wants to override, then
making them overridable will add unnecessary UI.

>> * Should settings be overridable at "solution folder" level too, hence
>> allowing a cascade of settings?
> We could do it (although it is not so important).

Yes, I don't think it so important, though it's probably not hard. So,
is it worth the effort (and UI clutter)?

>> * Should settings or group of settings be individually overridable? Or
>> should it just allow a project to override *all* settings? Does this
>> really need any granularity?
> Allow overriding at file type level is probably enough.
>> * Where should settings be stored? The solution file and the project
>> files? I feel this is better than a .userprefs-like file, since it
>> makes sure the settings stay with the project/solution.
> It has to be stored in the project file, since the idea is to share all
> those settings with all developers, and that would not be possible if
> you store it in userprefs.

The actual .userprefs files is right out, of course, since it should
never be shared. I meant some kind of userprefs-like file, e.g.
solutionname.style, to avoid cluttering the build files. However,
having it in the project file so that it's impossible NOT to share it

>> * Should setting be duplicated in the project in case it's opened
>> without the solution? Or should the project have a flag to say that it
>> expects settings to be stored in a solution, so MD can warn when the
>> solution isn't present?
> Since this is an uncommon case, I would just use the default settings.
>> * What settings do we default to when opening projects that don't
>> contain settings Do we automatically add default settings to the
>> solution files? Or fall back to a set of user preferences?
> All style and policy settings should be available as user preferences.
> Those would be the settings to use when creating a new solution.

Well, yes, that's a given; the user must be able to have a default
style for new projects. The question is whether we should write the
settings to the files automatically in the case where there are none
-- all MD-created projects should have style settings baked in upon
creation, but files from other sources would not.

It would also be nice to have a "smart default" mode that would infer
some settings (tabs/spaces) from the files.

>> GUI Infrastructure
>> =============
>> It's difficult to present all of these options in the GUI in a
>> scalable way, particularly the per-mimetype editor settings
>> * Should the settings be in the main "Project options" dialog or a
>> separate "Styles and policies" dialog? The separate dialog has the
>> advantage that the same dialog can be used to edit the user's named
>> styles and default style. It would also help to not overload the
>> setting treeview in the existing project options dialog.
> I think they should go in the project options dialog. We can have a
> "Coding Style" category and add a subcategory for each file type.

Don't forget that each file type will have sub-options, so the tree
will be at least three deep.

I would like the main panel for the "Coding Style" category to be used
to add / override / load / save file types, and dynamically insert the
corresponding subcategories into the tree.

I'm still not sure how this would work for allowing the user to manage
styles outside of projects.

>> * Should each panel have "use parent solution's style", "load/save
>> named style" etc options? Or should these apply to all styles?
> Load/save can be done at project level. Overriding at file type level.

So it won't be possible to save just (e.g.) a C# style; you'd have to
save everything?

>> * VS has a setting panel that can be used to add "file types" and set
>> the editing experience that's used for them. maybe we could do
>> something similar with per-mimetype styles -- the top-level panel for
>> editor setting would contain this list, and adding a file type would
>> cause it and its options to appear in the tree. Files not handled this
>> way would fall back to the "Other files" style (VS has an "All files"
>> option which aggregates the common settings from all files, with
>> tri-state checkboxes etc, but I feel this is overcomplex).
> In general, editing experience settings are not styles, they are about
> editor behavior. However it makes sense to allow binding a mime type to
> a known file type for which behavior and style settings can be set.

Yes, I meant use a similar UI but for styles, not editor experiences.

>> Named Styles
>> ==========
>> It should be possible to save a project's style, and apply this style
>> to other solutions/projects. However, I don't think it's viable or
>> desirable to synchronise these in any way. Once a project is created,
>> its settings should remain constant unless they are explicitly
>> changed.
> Agreed.
>> I also have a number of mockups on my whiteboard which aren't so easy
>> to express in email :-)
> Cool, feel free to post.

It'll probably be better when I have some actual stetic mockups or code.

Michael Hutchinson

More information about the Monodevelop-devel-list mailing list