IMO this should not inherit from nstate. Check is not made for displaying n-states, everything else then 2 states is going to break the displaying (same for efl.ui.check).

Sooo, with this latest update, this is in the final state. Is there anything i have missed?
The following commits do replace the existing widgets with this widget. I ported over the test codes, i was not totally sure about the stack test how it is supposed to work. There is also one bug in the stack widget test that i am currently trying to hunt down, it has to do with DEL events not beeing fired.

general update

general update

general update

Okay, after a while of searching and reading it appears the the integer "tool" is telling the number of the pointer down event, in case we have multiple down touches on the window. Should we rename tool to multi_counter?

This is already stable.

Mhm, I am really not sure when this is used or useful.

Looks fine to me.

Looks fine i guess?

Okay, i think we should drop tool here. There is device_type on the Efl.Input.Device which is accessable via Efl.Input.Event.device. This would resolve this issue.

Thank you :)

@Jaehyun_Cho Can you *please* *please* *please* be more carefull reviewing these meson changes. The eo files here are just plainly not installed anymore. because line 26 was removed. Additionally, its pure luck that this still works in meson, because you actually pass now a array with a array in array element nr. 0 followed by strings. This is not supported by meson and really only works by luck.

I really dislike the name has_pointer_caps, maybe "@property pointer_style" ?

I really dislike the name has_pointer_caps, maybe "@property pointer_style" ?

Seems reasonable ?

Overall: this seems like the object which is used to represent any kind of pointer-event, undepended from pointer,move click or wheel changes.

@zmike Can you build this branch Patch, open "elementary_test -to "Efl.Ui.Tab_Pager" click to transition, click on stack, then click a little bit around on the icons, see the wonderful animation, then click on scroll, click around on the icons, see the wonderful animation. Now if you click on efl again, do you also see some artifacts where the font "efl" is flashing around on the same position in the window ? I printed the geometry of the content, and the content is moved totally linear, there is no such jumping around geometry wise. Any ideas what could cause this ?

add a few fixes

Totally agreed. Doc's are also ready polished.

Thank you :)

correctly namespace everything

This misses all the types of the events.

docs docs docs docs

Seems good, however, do you think we could run into issues where 61 sec. on CI will kill the effective process before the usefull output (the testcases still running) is printed ?

In efl we have this weird semantics when it comes to signals:
Lets say we have a constant stream of press & unpress onto a edje part, the stream of edje signals is then:

• mouse,down,1
• mouse,up,1
• mouse,down,1,double
• mouse,up,1
• mouse,down,1,triple
• mouse,up,1
• mouse,down,1
• mouse,up,1

[and repeating like this]

update docs

• rename the widget

Lets ignore this and actually test the real items.

Lets solve this in some other way.

getuid must be on a platform that supports getpwuid, otherwise there is no way of getting the id...

Then you have to specify what you meant, before this directly emitted the clicked event. This is now not anymore the case, press and unpress is done from here, and according to that the clicked event is emitted (if there was no moving out). So right now, this works correctly afaics.

update to new API names, redo

update to new API names, redo

update to new API names, redo

update to new API names, redo

update to new API names, redo

update to new API names, redo

update to new API names, redo

update to new API names, redo

update to new API names, redo

update to new API names, redo

update to new API names, redo

update to new API names

update to new API names

update to new API names

update to new API names

update to new API names

update to new API names

update to new API names

update to new API names

update to new API names

update to new API names

update to new API names

@Jaehyun_Cho I really like this idea! JP started a concept for this a while back: https://phab.enlightenment.org/T6265 I think this does make a lot of sense. And should be applied, as this can be beneficial for other widgets as well. I will add this as a task once the main widget has hit master. We still can extend it. I want to focus on the mainfeatures for now. So we can merge this sooner than later :)

This misses a lot of testsuites. elementary for example.

add doc

enhance docs, and update util

I think you can pass the class directly, this removes the string compare, that safes us the strcmp.

No problem :)

So, with the latest update, most widgets do work again correctly.
So when a mouse down is followed by the mouse going out of the element, then press and unpress will be emitted (from edje) but no clicked event is emitted from the implementation. Which seems correct.

Make press,move-out-of-widget,unpress scenarios work take 2

Make press,move-out-of-widget,unpress scenarios work take 2

Make press,move-out-of-widget,unpress scenarios work take 2

Make press,move-out-of-widget,unpress scenarios work take 2

Make press,move-out-of-widget,unpress scenarios work take 2

Make press,move-out-of-widget,unpress scenarios work take 2

Make press,move-out-of-widget,unpress scenarios work take 2

Make press,move-out-of-widget,unpress scenarios work take 2

Make press,move-out-of-widget,unpress scenarios work take 2

Make press,move-out-of-widget,unpress scenarios work take 2

Make press,move-out-of-widget,unpress scenarios work take 2

Make press,move-out-of-widget,unpress scenarios work

Make press,move-out-of-widget,unpress scenarios work