[Monodevelop-devel] Per-project styles & policies

[Lluis Sanchez Gual]

El dt 30 de 09 de 2008 a les 14:18 -0400, en/na Michael Hutchinson va
escriure:
> 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.

Doesn't sound that hard ;)

> 
> >> * 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.

I would need to see a gui mockup to understand what you have in mind.

> 
> >> 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

I misread that paragraph. I agree it's important to have settings in the
solution and be able to override them in projects. I was thinking about
whether the full settings should be stored in the project or not, but
that's a different issue.

> 
> >> * 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.

In the idea of implementation I have, you would use the same gui for
setting and for overriding properties, so that would not be a problem.

> 
> >> * 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.
> 

Let's discuss all this when I come back from holidays.

Lluis.