Resolved and enabled CA1815 on the devs/lauromoura/stylecop branch.

Ooops. Looks like we might have an issue with this one on Mono (6.4.0.198 here):

Yes. I think it's needed. Because

In T7406#144792, @RCalixte wrote:

This was fixed in https://phab.enlightenment.org/D9868 and should make it into the next major release, but can hopefully make it into the next minor release.

update

https://sourceforge.net/p/enlightenment/mailman/enlightenment-users/thread/f7286c30-cff4-525b-4474-c4b567878459%40outerface.net/

There is no need to discuss something like "please make use of a macro here" or "this should be tested", nor are these *suggesstions*, they changes that i am requesting.
I am also not saying that discussions are not allowed, but coming to a discussion with a argument "its also like this somewhere else" is not going to be usefull at any rate.
Replying to a inline comment where we would like to have a change with "we will do it later" is also not really a discussion, why would you start later on again on old code file fixing something that was said ahead of time, even if it could have been fixed before this piece of code would have even landed ? That makes no sense to me. Fix it now, no need to discuss things, no need to revisit things, and more testing, review can happen.

@bu5hm4n first of all Thank you for your help

Okay, i am starting to be annoyed by replies like this. I am called here to do review, i do review, and all that is coming back is "we will do it later" "its used somewhere else like this" "we should not document concepts like this".

All our comments are we will do it later !!, this is not true, check the comments
These changes and patches talk about specific features, we will fix any new change we cause, but fixing old stuff should be done in separate patches, not these ones

Making Xavi happy is VERY important!

Okay, i am starting to be annoyed by replies like this. I am called here to do review, i do review, and all that is coming back is "we will do it later" "its used somewhere else like this" "we should not document concepts like this".
There is no golden rule about what we declare as easy to read code, however, this block is the perfect example of what it is NOT, it takes ONE single macro to get this cleaned up, where you have something like MY_MACRO("off", EVAS_TEXT_STYLE_PLAIN, EFL_TEXT_STYLE_EFFECT_TYPE_NONE) one call for each line up there. Which is WAY more readable than what is there right now. We also do EXACTLY this macro stuff ALL over the place, so the argument of "used in other part of text" is completely irrelevant and does not mean anything.
Other people have to READ that code again, have to MAINTAIN that code in some way, and someone on a bug-hunt will likely come across it, why should we make the life of these people harder ?
Have you ever heard of the "Broken windows theory" ? Whenever there is something broken or ugly, someone else, who does not want to make it any better will exactly refer to this code "eh, it was done like this before", could you please try to get off that attitude a bit ? This code here will last a long time, and why would you want to start with a hard-to-read version if you can invest 5 min. and make it nice ? (Same applies to other comments and revisions regarding tests, or string parsing, or or or )

make xavi happy

I think this is OK regarding the API. I will take care of the rest of the documentation concerns in future patches.

I have merged some of these API functions today, so this patch will most certainly not apply cleanly anymore. There are still a few APIs on this that are not in upstream yet (mostly cursor APIs, and the input rectangle one).

I understand,
We apply our theme on the popup.
commit 822680869ff70a0f69dd383e3a810f3f18462dbc removes the possibility of not drawing the shadow.
Pity.
I rewrote our popups and deleted the arrows.
I already have enough patches to work correctly on X.
Thank you for watching.

In D10542#200219, @segfaultxavi wrote:

I did find open comments in efl_text_cursor.eo for example

One big question regarding this header and footer is...
how we support horizontal header/footer.

This does happen - the RUNTIME linker (ld.so) will search and if it finds the libs in a system dir it seems to prefer those to the ones in the tree. this happened under autofoo and still happens with meson it seems. i know they SHOULD be using an rpath which SHOULD make the in-tree libs preferred ... but that seems broken when running eolian_gen and edje_cc as part of the build... :(

I did find open comments in efl_text_cursor.eo for example.

is this accuracy really needed ?

• fix implicit casting int to a unsigned int
• added EINA_SAFETY_CHECK
• updated docs

restore everything, just remove a 'f' characters

• keep meaning of removed comment.
• modify a corresponding testcase.

In D10542#200189, @segfaultxavi wrote:

There are still many open comments.

update documentation

This has been stopped for more than a month and we didn't come up with a better name.
Plus, the only person against "arrangement" is Mike who won't be available for another month...

Looks good to me!

I am pretty much fine with this,i think we can still move to python if there are issues. I am also not sure if the doc build works anywhere except linux ... :/

There are still many open comments.

I agree that change cosf to cos.
But in my opinion, we should to keep note messages. And you also need to change the test. (src/tests/eina/eina_test_matrix.c)

No problem, @zmike is on vacation ... :)

Hi @bu5hm4n :)
sorry I don't know how to i get event name in _efl_ui_layout_base_efl_object_event_callback_priority_add function.
Can you tell me more detail?
And most of all I don't know why desc == EFL_CANVAS_GROUP_EVENT_MEMBER_ADDED was added.
7ad8acc290f078aa9d2bfd32ec15a4e5677ab01f I checked this patch but I still don't understand.
So I couldn't find a way to improve this problem and made this revert patch.
I hope @zmike to check this :)

In D10607#200161, @AbdullehGhujeh wrote:

@bu5hm4n

can you check that all branches of the parsing function is checked and tested (also with asan enabled)?

I have tested only new code.

I am unsure what are the plans for Efl.Text.Format, but having Format and Style interfaces is very confusing. We should find names that indicate what kind of properties each of these interfaces hold.

• fix implicit casting int to a unsigned int

can you check that all branches of the parsing function is checked and tested (also with asan enabled)?

I have tested only new code.

I think the errors in efl_text_attribute_factory.c should be done using EINA_SAFETY_ON_FALSE_RETURN. Which will also print the conditions, otherwise these errors are not really helpful.

The file src/lib/efl/interfaces/efl_text_annotate.eo must be removed from the tree. ninja test is failing for me because it picks it up.

If there is no better alternative names for "content_" prefix and "arrangement",
I think we can go with current definitions.

I think this looks good now.
Is it ok to remove @beta ? or any other opinions ?

These are my thoughts:

• I think Efl.Ui.Title_Item can be useful. I like the name too.
• Efl.Ui.List_Double_Label_Item looks useful too. However, I think it will look strange if it is only available for List and not for Grid. We should provide it also for Grids even if it's not commonly used. About the name, how about Efl.Ui.Double_Text_Item, or Efl.Ui.Default_With_Subtitle_Item?
• I also think item padding should be handled by the container (implementing the Efl.Gfx.Arrangement interface). Inserting items to achieve padding will get messy very soon :)

Use the same check retry logic as we have for the normal runs

rebase

I'm thinking to adding more item styles,

There was a conflict after D10616 but I resolved locally.

@zmike @q66 any idea?

Once you start adding dependencies between tasks, you are building a "patchset" (or "stack"). In the five tabs just above the diff (Files, History, Commits, Stack and Similar) you can select Stack and see all your dependencies and dependent patches (it can show very complex trees).
If you now try to apply a patch with arcanist (arc patch Dxxxx) it will first apply all its dependencies.

In D10646#200101, @segfaultxavi wrote:

In D10646#200033, @ali.alzyod wrote:

@bu5hm4n I do not know if it is possible to make this patch base on another patch. (this patch is dependent on D10542)

In the Phabricator web interface, in the top-right menu box, there's Edit Related Revisions. There you can add "parent" revisions, which means that your patch depends on them.
Arcanist will do this automatically if your commit message includes the words "Depends on Dxxxxx".

In D10646#200033, @ali.alzyod wrote:

@bu5hm4n I do not know if it is possible to make this patch base on another patch. (this patch is dependent on D10542)

https://travis-ci.org/Enlightenment/efl/builds/613538455

Resolve required changes

Remove whitespace

Resolve required changes

In D10692#200088, @segfaultxavi wrote:

Hahaha, I always wondered why you add the description after submitting the patch. What process do you follow?

Hahaha, I always wondered why you add the description after submitting the patch. What process do you follow?

In D10692#200083, @segfaultxavi wrote:

Can you please explain in the commit message what is the exact problem you are trying to fix, and how are you fixing it?
Otherwise, this is very hard to review.

Can you please explain in the commit message what is the exact problem you are trying to fix, and how are you fixing it?
Otherwise, this is very hard to review.

We use the edje file path gotten from edje_object_file_get. (@cedric any comments?)