In D9300#171719, @bu5hm4n wrote:

@Jaehyun_Cho D9306 fixes the issue in the spotlight widget, the underlaying issue is still present, but please not solved like this :)

Constant is finally, well, constant :)

Updating after big changes.

Update after doc cop ticket.

Another round with some fixes.

Rebase and update after initial fix in a previous commit

Well, making these constructors private would mean that we would have to add empty default constructors above in the inheritance tree, and these constructors wold have to be visible somehow. So, the current protected constructors with the remark of being only for internal use seems to be enough.

Adding Cedric as this may change how MVVM Models work.

I've pushed some build fixes to devs/lauromoura/csharp_examples but there seems to be some runtime issues.

Resolved with D9014 (the WrapperSupervisor commit)

Fix indentation

Update

We've tried measuring the eo benchmarks for it using the release build[1] on an dell xps 15 9560 running ubuntu 18.10.

Concrete classes serve as a wrapper for eventual private classes that implement the given interface, akin to the *Realized classes for abstracts.

In D8582#161167, @segfaultxavi wrote:

I think this can be solved very easily by making C# suffix parts with Part automatically, just like events. Then we can remove the restriction that parts cannot be named like other properties (just like events).

Let me explain:

We have different kinds of symbols in EO files: Namespaces, Classes, Methods (and Properties), Events and Parts.
In C they can have the same name, symbol clashes are not a problem, and this is why originally our hierarchy had lots of duplicates.

When we started implementing bindings, some languages had issues with the symbol clashes: Python and C# cannot have a class named like a namespace (not even changing the case, because in Python class hierarchy maps to the filesystem, and the Windows filesystem is case-insensitive). In C# a property cannot have the same name as the class, etc.
We started solving these issues in different ways, and I think this was a mistake. For example, in C#, events are automatically suffixed with Evt so clashing is resolved, but not so parts.

As a result, these are the current rules that eolian is enforcing (as far as I understand):

• Classes cannot clash with Namespaces
• Methods (and Properties) cannot clash with anything
• Events cannot clash with other events
• Parts cannot clash with anything
  
  I think these rules work nicely for all cases except parts, which we have not used much yet. So, if the C# bindings suffix parts with Part just like events are suffixed Evt we can remove the restriction on part names and we can use more sensible names like text, icon and extra (without prefix). Of course, names will still need to be unique inside a widget's hierarchy (a part cannot have the same name as another part up in the hierarchy).
  
  What do you think @cedric, @SanghyeonLee, @lauromoura, @q66 ?

This is just a struct to wrap the event parameters. The event documentation itself is already present in the EventHandler field.

Update after Xavi's comments

I had added this fix in D8811 alongside others. Added you as reviewer there.

Update fixing typo.

This ticket has been closed as spam because it lacks a description. If this ticket is not spam, please reopen it after adding a description.

Update with test and extra fix

Results of expedite-cmp (I've patched it to aggregate the average values of the comparison files in the second column):

I caught this error after doing a fresh install without old modules installed.

E compiles correctly after this.

Removed uneeded initializations

The failure occurred because the Dummy.TestObject.set_value implementation either freed the stored value or created the new one. This worked normally outside of debug mode probably due to mempool reusing the memory address. The debug build uses the pass-through mempool, making the problem appear.

Rebase and fix comment.

Here I get a segfault when trying to create an empty Eina_Value (before assigning). And looks like there is more instability regarding Eina (at least with C# apps). Some calls to Eina.Log.Error also made the program crash. Will investigate more.