Bug 3109 - MonoMac samples and document project template have old grouping
Summary: MonoMac samples and document project template have old grouping
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: Mac Add-in ()
Version: 2.8.5
Hardware: Macintosh Mac OS
: Lowest enhancement
Target Milestone: ---
Assignee: Chris Hamons
Depends on:
Reported: 2012-01-27 05:36 UTC by Matthias Fuchs
Modified: 2016-01-12 21:05 UTC (History)
3 users (show)

Is this bug a regression?: ---
Last known good build:

screenshot of the project outline view in monodevelop, showing the bug (4.43 KB, image/png)
2012-01-27 05:36 UTC, Matthias Fuchs

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Matthias Fuchs 2012-01-27 05:36:03 UTC
If I open a monomac sample, the structure in the project side panel looks likes this:


If I create a new monomac project it looks likes this:


So the 3 corresponding files are not grouped correctly!
Comment 1 Matthias Fuchs 2012-01-27 05:36:43 UTC
Created attachment 1277 [details]
screenshot of the project outline view in monodevelop, showing the bug
Comment 2 Miguel de Icaza [MSFT] 2012-01-27 09:52:35 UTC
This might have been a regression in MonoDevelop or in our templates for MonoMac

Michael, does this ring any bells?
Comment 3 Miguel de Icaza [MSFT] 2012-01-27 09:56:07 UTC
For now, as a workaround, use the MonoMac Document template instead (which you want anyways as this project uses APple's new NSDocument support which does a lot of the work for you)
Comment 4 Mikayla Hutchinson [MSFT] 2012-01-27 14:58:35 UTC
This is by design. Since the introduction of Xcode 4 integration, there is no longer a strong relationship between xibs and classes, so the grouping was changed.

The document template and the samples should be updated to match.
Comment 5 Mikayla Hutchinson [MSFT] 2012-01-27 14:59:48 UTC
To clarify, there is no longer a strong *one-to-one* relationship.
Comment 6 Matthias Fuchs 2012-01-28 08:04:16 UTC
Nonetheless, the files (designer, controller, xib) belong together from a users/developers point of view and should somehow be grouped together and not live side by side.

Personally I'd prefer the grouping as it is in the samples. But the controller as group node containing the xib and the designer.cs would also make sense to me.

The current state though is not more than suboptimal.
Comment 7 Matthias Fuchs 2012-01-30 14:40:26 UTC
Actually it would be best to have this structure:

-- MainWindow.designer.cs

And separate cs files for all classes that are declared as partial in the .designer.cs.
Comment 8 Mikayla Hutchinson [MSFT] 2012-01-30 17:32:22 UTC
That's really not how it works.

The designer file is (sort of) a designer file for the class. Since Xcode 4, the xibs do not contain any information for which we can generate code. A xib does not define classes or action/outlet members, but it can refer to any number of classes and actions/outlet members in them. Also, multiple xibs can refer to each class. So there simply is not a strong 1:1 relationship in the way that you expect.
Comment 9 Matthias Fuchs 2012-01-31 04:06:38 UTC
I know that there is no 1-1 relation between a class and a nib file, but as there are several classes in the designer.cs (like MainWindow, MainWindowController) it does more belong to the nib file (as subnode) as to any other cs file (like MainWindow.cs in my case).

If several xib files refer to the same file, then simply each xib file has its own designer.cs as subnode containing partial class definitions. Still it would be possible to have one "implemenetation" class outside the xib node.


-- MainWindow.designer.cs (partial classes MainWindow, MainWindowController)
-- SubWindow.designer.cs (partial classes SubWindow, SubWindowController, MainWindowController)
-MainWindowController.cs (implementation)
-SubWindowController.cs (implementation)
-MainWindow.cs (implementation)
Comment 10 Mikayla Hutchinson [MSFT] 2012-01-31 11:54:13 UTC
I think you misunderstand the nature of the designer files in MonoMac/MonoTouch projects. Since Xcode 4.0, they do not represent code generation. They actually store the outlets and actions - they are simply the part of the class that can be modified by the Xcode integration when you edit the header file in Xcode. You could even have class files that are not used by a xib at all. Also, multiple designer parts for each class isn't useful - all except the first would be empty.
Comment 11 Matthias Fuchs 2012-02-01 03:46:55 UTC
"... store the outlets and actions ..:"
so they "belong" to the xib file!?

"... You could even have class files that are not used by a xib at all..."
yeah, that's fairly normal ... ?

My idea is, that one or more  xib files contain one or more objects (be it controllers, windows, widgets etc). In IB each object has some outlets and actions that link to class defintions (header files). These header files are parsed by Monodevelop and a designer.cs is generated. The designer.cs contains one ore more partial classes containing the classes and  their outlets and actions defined in IB.

Is that correct?

If yes, than each nib files should have one corresponding designer.cs a its subnode, because that is the most logical way of presenting the relationsship to the user.

In a newly created monomac application, the MainWindow.designer.cs is under the MainWindow.cs, which simply makes absolutely no sense. The MainWindow is the implementation part of the partial class defined in the MainWindow.designer.cs

But MainWindow.designer.cs also defines the partial MainWindowController.cs which lies besides MainWindow.cs! Even the other way round would makes more sense.
Comment 12 Mikayla Hutchinson [MSFT] 2012-02-01 13:00:48 UTC
> "... You could even have class files that are not used by a xib at all..."
> yeah, that's fairly normal ... ?

I meant classes that are exposed to the objective-C world with a [Register("SomeName"] attribute that therefore show up has headers in Xcode. If you add an outlet to one of those, where would the designer be created and grouped? The class is the only place that makes sense.

IB files do *not* define or contain outlets and actions, they contain serialized objects that may be connected to outlets and actions that are defined in classes. Multiple objects in multiple xib files may connect to particular outlets/actions.
Comment 13 Matthias Fuchs 2012-02-21 04:32:10 UTC
Hmm, wouldn't it be nice to limit the possible ways to link classes and outlets and do something like the following:

In interface builder define a User interface item identifier for each widget you want to access in c#.
In the XIB file the widget, the identifier somehow has to be connected to the actual serialized widget, right? Though some (most?) widgets don't implement the NSUserInterfaceItemIdentification protocol, it still may be possible to access an object from the XIB with this identifier.

The result should be one designer class for each xib containing classes for all objects in the xib. So if there is one window (id=main_window) containing one button (id=close_button) then the class would look like this:

partial class main_window : NSWindow {

public NSView GetChild(String identifier) {
    return this.subviews.getbyidentifier(identifier);

It would then be possible to wire up the widgets in c# code by implementing a partial class the simply uses getchild() to access the child widget and then uses c# style event handling and property assignment (for properties not accessible in IB).

I don't know if this approach is possible at all, but it would be much more c# friendly then the cocoa way of doing things.
Comment 14 Matthias Fuchs 2012-02-21 05:38:13 UTC
Another option would be to add a partial designer class for each registered partial implementation class to all XIB's designer.cs files.

If you then add an outlet or an action from XIB 1 to Class 1, Class 1's partial designer class in XIB 1's designer.cs is updated (Class1's partial designer class in XIB 2's designer.cs is empty). If you then link XIB 2 with Class 1, the XIB 2's designer.cs is also updated.

Class 1's partial implementation class (located somewhere in the project tree, not beneath any XIB) contains the actual implementation.

This way it's possible to link multiple XIB's to multiple registered classes and still keep a logical link from a .NET programmers mind ;-)
Comment 15 Mikayla Hutchinson [MSFT] 2012-02-21 15:22:24 UTC
AFAIK NSUserInterfaceItemIdentification doesn't have anything to do with IB. A single xib file could be used to instantiate many windows that would identify differently.

Your first idea basically is an alternative to outlets that's like the XAML codebehind model. However, it's only possible if we enforce a 1:1 link between owner classes and xib files. It also will incur a fairly significant lookup cost.

The second doesn't really make sense to me. Anything in either partial designer file can be connected from the other xib - how do we determine which outlet/action goes in which designer file?
Comment 16 Matthias Fuchs 2012-02-22 04:31:22 UTC
Explanation for second option - you have this structure:

-1.designer.cs: contains no class definitions

-2.designer.cs: contains no class definitions

-registered class 1: exposed to the Xcode project, but not yet referenced by outlets or actions
-registered class 2: exposed to the Xcode project, but not yet referenced by outlets or actions

You open up the XIB 1 and Xcode starts. You have 2 objective-c header files: class 1.h and class 2.h.

You link a textbox in XIB 1 to class 1 and to class 2. Save and return to monodevelop.

Now the structure looks like this:

--partial class 1: contains outlet to textbox in XIB 1

--partial class 2: contains outlet to textbox in XIB 1

-registered class 1: can access outlet to textbox in XIB 1 through partial class 1 in 1.designer.cs
-registered class 2: can access outlet to textbox in XIB 1 through partial class 2 in 2.designer.cs

That makes it really clear - at least to me - what XIB is how connected (outlet or action) to what class.

Maybe it's not perfect but way more understandable than the default behaviour in the monodevelop templates.
Comment 17 Chris Hamons 2016-01-12 21:05:18 UTC
This has been around since 2012 and has no action. We've gone from MonoMac, to XM Classic, to XM Unified, and now have storyboard support. I don't believe we're going to take action on this, so I'm going to close.