I apologize. I've submitted a patch to fix it. 099eb2c315a277bda10f41709d7f936b0ae7fb20

That's right~
Thank you :)

I think we need to consider the lazy loading method or event callback.
This can be separated into the following 2 scenarios.

I think that removing @property type is better.

rebase

I think you understand me that I do not want to make argument but I also want to make our widgets better than now like you :)
I asked @Hermet a piece of advice about this concept and I realized some of my assumption may not be right from other point of view.

Beyond the name of Single_Display, I still think that we should separate Pager and Stack.

About Single_Display, now I understand your point. However, at least I needed your explanation to understand the meaning of it.

In D8784#161987, @bu5hm4n wrote:

@Jaehyun_Cho

@segfaultxavi and I have been brainstomring about a new name for this. We came up with the following scheme:

Efl.Ui.Single_Display.Container -> The container itself, what Efl.Ui.Smart_Container is right now
Efl.Ui.Single_Display.ViewManager -> manages the animation / user interaction / can manage additional stuff and settings.
Efl.Ui.Single_Display.Indicator -> What Indicator is right now

What do you think ? IMO this expresses better what it does, and a page_size on a ViewManager sounds more realistic then on a transition object.

In D8784#162138, @bu5hm4n wrote:

class Efl.Ui.Smart_Container.Util:
   @class stack : Efl.Ui.Stack_Container : This functions returns you a ready configured object which can be used just like a created stack object.
   @class pager : Efl.Ui.Stack_Container : The same as above, just for pager.

I think the idea which attaches transition to container is great.

I think there are some misunderstandings between us.

You commented that transition classes will cover unique features for each container class.
IMHO, it may not be right for some cases because it looks weird if "transition" class supports "container" features.
Although you mentioned why you added "indicator" and "page_size" to smart_container, but I don't think that those properties can move to "transition" class. (they look like "container" features)
I am afraid that there would be more properties like "indicator" and "page_size" which is perfectly required for some classes but not exactly for other classes.

I totally understand your point.
If I understand your comment correctly, the main benefit of this patch is "reducing the maintenance efforts by integrating 2 classes into 1 class".

Sorry I am late to give you comment about this patch.

When I tried to build with meson, build error happens because efl_gesture_events.eo is dependent on efl_canvas_gesture_xxx.eo

need to check meson build

Could you check and remove EINA_UNUSED which are not supposed to be used?

@CHAN is updating this patch to support EFL C#.

is pd->base freed when relative layout is destructed?

I think there is a typo in the commit description.

This fixes build error on efl_custom_exports_mono.c.

It seems that this issue has been resolved by commit 55751f12044c5939b189d9ef149d82e8f331811a ..
Sorry to interrupt..

Up to now, elm_object_item APIs in elm_widget_item.eo are not in documentation because the group was not defined. (i.e. defgroup)

What I am worrying is that there are 2 types of parents here, object parent and widget parent. ;(

There is no indentation rule on StyleCop but normally indentation is automatically applied when I type inside the namespace bracket.
So I was not sure which way is better.

removed namespace indentation in efl_csharp_application.cs

Thank you :)

@bu5hm4n
Yes~ thank you :)

Thank you!! :))

You are right. My comment was out of this topic.

@bu5hm4n
Thank you!! It perfectly works :)
There is no backward compatibility issue as well!

There is one thing we need to think about.

Thank you! I think a new patch is required to change the current disabled calculation logic.

I think we have 2 ways to resolve the counting problem.

Although I may not fully understand your point, but I understand why counting way is adapted here.

I am not sure which is better either 1. apply 4 spaces indentation inside each namespace or 2. do not apply it (which is current patch).

This patch is going to be submitted after 1.22 release.

I see your worries about removing the namespace "Csharp".
I think your worry is basically the collision of the namespace.

Thank you for notice~
This task is done :)

OK, I will make a patch to change the name of all "able" classes/interfaces/mixins later :)
BTW, since @bu5hm4n requested to wait for 1.22 release, I think I should not push this patch until 1.22 release.

I made a patch D8463 which moves the enum Efl.Csharp.Components out of the namespace Csharp.
(i.e. Efl.Csharp.Components -> Efl.Components)

@bu5hm4n
I understand your point. Thank you :)
When I have some new brilliant ideas about the namespace Csharp, then I will share with you.

change Efl.Ui.Text_Cursor_Selectable to Efl.Ui.Text_Selectable

@bu5hm4n
Thank you for the feedback :)
I wanted to apply this change before release but as you say let's wait until release because these interfaces are @beta ;)