[MonoDevelop] Version Control UI

[Mike Krüger]

  Hi

>>
>> For consistency with aspx and xaml I would expect:
>> MainWindow.gtkx
>>      MainWindow.gtkx.cs
>>      MainWindow.gtkx.designer.cs
> I was prototyping that grouping too, but i felt that having cs file as a parent
> would be better. My reasons were :
> - similarity to WindowsForms designer in VS which have
>    MainWindow.cs
>      MainWindow.Designer.cs
>      MainWindow.resx
> - unlike aspx and xaml, gtkx files are not supposed to be edited directly
>   (although I've done some work to make editing more convenient , now
>    it uses XmlEditor for display)
> - aesthetics issues, mixing on the same folder level ordinary cs files with
>   gtkx ones looks not nice for me :)
> - usability, editing source file happens more often than working in
> the designer,
>   if gtkx file would be a root, easy navigate to main source file is a must.
>   I don't see how we can rid of this combined (designer/source) view, especially
>   that people are accustomed to that.
>
Your grouping is the right grouping. All other files than the 
MainWindow.cs are only there for one reason:
Make the life of the forms designer easier.
- The forms designers started out parsing the InitializeComponents () 
method from the forms class. I don't think that it's good to confront 
the user with this technical complexity (and you got the point - aspx 
etc. is for direct editing where gtkx files are only helpers for the 
forms designer no user should ever touch directly).

IMHO you did the right thing - gtkx files are monodevelop only - it 
doesn't make a reason to build the project this way (try to think what 
happens when the project is opened in vs.net or #develop).
I think the designer/source view is good for the gtk# designer. All IDEs 
(expect VS.NET - maybe a technical limitation in their IDE?) do a split 
system for forms.
Changing that needs a very good reason - because the VS.NET way has 
usability issues as well.

> It makes sense to integrate stetic source/designer buttons with bottom
> pad (having multiple separate contents instead
> aggregated one would further cleanup code). My only concern is that we
> will have at least six tab pages : source (the same as a abstract
> content?)/designer/groups/diff/blame/log. Would not be a bit clunky ?
We have that right now as well >but< with one important issue: the 
stetic designer implements it's own subview system. I'll move the 
diff/blame/log thing to the right when it's too clunky - that should 
solve the issue.

Regards
Mike