Yea....not going to happen

Hey hey hey! nice find! yeah that is now implemented :)

i guess this one should be closed, no ?

Well, if you need to use another lib that you need to init, then you can just do it in Efl.Csharp.Application, or in the main method, and later on call launch. So this is not a problem ? (If the other lib also needs to have a mainloop running, than this is not going to work anyways, as efl needs to do that, no matter if you use Efl.Csharp.Application, or Foo.Init() )

In T8493#147374, @segfaultxavi wrote:

Just a thought: What if the user's application cannot inherit from our Efl.Csharp.Application because it already must inherit from another class?
Due to another library's restriction, for example.

Just a thought: What if the user's application cannot inherit from our Efl.Csharp.Application because it already must inherit from another class?
Due to another library's restriction, for example.

@lauromoura yes! thank you :)

D9712 seems to have resolved this. Can we close this one @Jaehyun_Cho ?

In T8165#142364, @YOhoho wrote:

If "inherited generated classes" are eo custom classes that inherited efl classes, internal will occur compiler error.

If "inherited generated classes" are eo custom classes that inherited efl classes, internal will occur compiler error.
e.g.

mcs -d:EFL_BETA -target:library -out:src/tests/efl_mono/efl_mono_test.dll -r:src/bindings/mono/efl_mono.dll src/tests/efl_mono/dummy_child.eo.cs src/tests/efl_mono/dummy_numberwrapper.eo.cs src/tests/efl_mono/dummy_test_object.eo.cs src/tests/efl_mono/dummy_test_iface.eo.cs src/tests/efl_mono/dummy_inherit_helper.eo.cs src/tests/efl_mono/dummy_inherit_iface.eo.cs src/tests/efl_mono/dummy_part_holder.eo.cs src/tests/efl_mono/dummy_event_manager.eo.cs src/tests/efl_mono/dummy_constructible_object.eo.cs
src/tests/efl_mono/dummy_part_holder.eo.cs(83,80): error CS0122: `Efl.PartConcrete.NativeMethods.efl_part_get_ptr' is inaccessible due to its protection level

With this patch

diff --git a/src/bin/eolian_mono/eolian/mono/function_definition.hh b/src/bin/eolian_mono/eolian/mono/function_definition.hh
index a0f28df..149272a 100644
--- a/src/bin/eolian_mono/eolian/mono/function_definition.hh
+++ b/src/bin/eolian_mono/eolian/mono/function_definition.hh
@@ -61,7 +61,7 @@ struct native_function_definition_generator
     if(!as_generator
        (
         indent << eolian_mono::marshall_annotation(true) << "\n"
-        << indent << "public delegate "
+        << indent << "internal delegate "
         << eolian_mono::marshall_type(true)
         << " "
         << string << "_api_delegate(" << (f.is_static ? "" : "System.IntPtr obj")
@@ -76,7 +76,7 @@ struct native_function_definition_generator

In T8162#141719, @Jaehyun_Cho wrote:

@lauromoura
It is confirmed that SA1402 is not mandatory but it is recommended.

Since SA1402 is problematic with eo and SA1402 requires additional effort, I think it would be better we do not apply SA1402 for now.

We focus on other mandatory rules and major issues and then we may consider SA1402 later when we are able to do it.

Resolved in D9816

@lauromoura
It is confirmed that SA1402 is not mandatory but it is recommended.

@lauromoura
I will ask the reporter who raised this issue in detail and I will let you know.

If actually needed, we could disable this rule for generated code and keep it only for the manual code.

In T8162#141476, @Jaehyun_Cho wrote:

@Jaehyun_Cho, what would be the reason for these requirements? (We're not questioning them, just trying to understand the issue better. :) )

The main reason is to make class name and cs file name same :)
As you know, efl_ui_layout.eo.cs contains class Layout in the namespace Efl and Ui.
Therefore, it was suggested that efl_ui_layout.eo.cs should be renamed to Layout.cs which is the same name with class Layout. And Layout.cs should be moved to Efl.Ui namespace directory to avoid duplicate cs file names.