This revision is divided into D11517, D11518, D11519

In D11513#219509, @segfaultxavi wrote:

This patch looks very similar to D11511. Can you take into account the comments I made there?

Updating D11514: evas_vg: refined the documentation for evas vector APIs

evas_vg: refined the evas vector APIs set

update source

@segfaultxvai
hello, thanks for the comment, I will divide this path for readability(D11513 is the first path of this)
and in case of other comments, I will change to follow your comments.

In D11511#219479, @segfaultxavi wrote:

Looks like you are defining new enums here that are already present in Eo files. Can you explain why?

=> because I think legacy APIs should use legacy eo files, so I defined evas enum types

ex) for using evas_vg_shape_path_set.

I think @zmike worked on the move of this stuff from Legacy to Eo some time ago, it might be worth asking his opinion.

update cdes

abandon this revision

evas_vg: refined the documentation for evas vector APIs

update tags

updated version for new evas enums

I will update as other patch

updated codes for adding documentation

I checked this codes on my desktop and it is reproduced with x11 environment.
In case of pasting twice, it is blocked by below codes.

update the codes

add @beta tag

modified the codes

Hi, lauromoura,
I made a patch that synchronizes with the upstream code.
Actually the upstream eolian grammar has been changed from 2019.Oct
so I added more verbs and modifyed the event and function names.
You can apply this patch after rebasing.

After zmike's refactoring the popup, the enum will be removed

In fact, I don't have enough time to handle this since I have to migrate upstream code to tizen until next wednesday.
and I should make the entire EflSharp UnitTest set until end of september. I think the amount of TC set that I have to make quite large.
so I'm not sure to answer :(

@zmike
You mean that making the parts class for the buttons, right?
I also agree with your opinion and I think the parts should implement content and text interfaces for the setting text and icon of buttons

@zmike
I talked with woohyun about this refactoring for popup,
we have to finish this task until early september since we will start the release for EflSharp after the middle of september.
please take care of this schedule.

@zmike
The application developers in tizen need two types of popup such as context style and alert style
In case of the context style like elm_ctxpopup of efl needs priority align feature because the context popup should be shown depending on mouse position and in the screen boundary.
when the context popup is created near the screen boundary, the priority is used to find the optimal position of the context popup which the user wants.
In case of the alert style like elm_popup of efl needs align feature because some developer want the popup to be aligned whenever the screen is resized.
However If there are some ways to set the priority using algin hints or find optimal position, I think we can remove the priority set API :)

@zmike
Hi, I agree to your opinion, the usage of the anchor popup align is different from base popup.
so I think the align feature in anchor popup should be separated from Efl.Ui.Popup.Align
and make the anchor popup has its own priority align features.

I agreed with you :)
abandon this patch

I agree to bu5hm4n's opinion and I think segfaultxavi's idea can be good alternatives.
It looks good for me :)

The enum values support the alignment setting for the very high frequent alignment.
I think this is the important factor from the user perspective.
Also there need to add left_top, right_top, left_bottom, right_bottom enum values.

@bu5hm4n
I think the max_size_hint is different with popup_size.
the max_size in efl_ui_popup means the maximum size that the popup can expand.
If the max_size_hint is used to change the popup size, the popup will not be expandable.
Therefore, I think it's not good to change popup_size to max_size_hint.
In case of the alignment API of popup, It is designed to notify the options to the users.
To use this API makes the code simple and easy.

In D8696#158431, @q66 wrote:

No, it's not intended, but all you need to do is simply remove the first is_enum check and leave the second one where it is.

update code

In D8696#158404, @q66 wrote:

The goto is unnecessary, syntax error means a long jump

@q66
Hi, you mean these codes are intended?
but actually the following codes are not reachable.
2198: if (is_enum)
2199: eo_lexer_syntax_error(ls, "enums cannot have @free");

update code

modify the code

modify the code

update the codes

update the code

update the code

currently, this patch is not available. I will abandon this :)

update interface scrollable code

apply indentation

updated source code

updated source code

remove the unnecessary function

@raster, @cedric
applying 'efl. 'prefix for parts is finished I think. could you verify this patch?
and then I will make the new patch for new signal policy as you and jaehyun mentioned :)

apply efl_part name policy more

@cedric, @raster
I just finished removing the legacy part name and added "efl." prefix to all parts used in source code in edc/efl :)

update the code

update source code

update source code

update the code

modified more parts