There are some other stuff that needs to be update for these examples to actually compile but these are good.

Example working with Basic after this.

The stringshare check has been fixed with the last string changes but the lock still remains.

In D9717#184121, @Jaehyun_Cho wrote:

@lauromoura
I cannot find a proper way to install Efl.Csharp.1.23.0.nupkg on Visual Studio Code on Ubuntu.
But that .nupkg can be installed Visual Studio on Windows.

I added DO_NOT_MERGE as we are in freeze and this is quite a big change in the build files.

I'm not sure we can remove all these functions from the Concrete classes yet.

Is this still valid or should be abandoned given the changes since to both the EFL hierarchy and C# support for mixins/interfaces?

I thought about generating and installing the nupkg but it seems referencing the DLL directly in the csproj like the code below would be enough.

This fixes the tests and unbreaks master.

Updated, now installing both the nupkg and the dll.

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

Nice catch!

Abandoning as autotools is no more.

Abandoning as this patch may need a lot of work just to rebase after all MVVM changes since last update.

There was an implementation of TreeView in D7242 late last year but this patch is outdated with the current changes in mvvm, interfaces, etc.

Marking as resolved after D9867.

Updating with replacing the non-default type_c_type_get usage with the new param/return_c_type_get functions.

Update after applying D9752.

Need to change this after D9752 lands.

Marking as resolved given D9690 added support to generate partial classes.

Messed up with revisions from another task. Sorry.

Fix code skipping doc reference conversion for property accessors.

Update by fixing property accessor generation.

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.

In T8162#141471, @Jaehyun_Cho wrote:

@segfaultxavi
The main issues of this task are as follows.

1. All C# source files (.cs) should be located in the directory named fully-qualified namespace.
   • e.g. cs file for class Efl.A.cs should be located in directory Efl. This means that Efl/A.cs

This looks good for the *Concrete classes.

Working good. Sorry for the delay reviewing the first version.

Needs rebase after D9690 (conflicted in klass.hh)

Closing as it was commited in D9577

In D9800#182326, @segfaultxavi wrote:

protected methods have been removed from interfaces, but they wrapper properties still exist. They should be removed too, right?

In D9569#181494, @YOhoho wrote:

In T8093#140311, @tasn wrote:

@woohyun, I'm going to reshuffle things in the text space so I wouldn't worry about making a decision/change yet. I'll take a look at the WPF naming scheme when changing though.

@tasn have a plan to reshuffle text space. I think we can discuss after text class refactoring if there is still name conflict.

Good to go. Examples to be updated in another diff.