Thank you, should the same be done with the box revision from yesterday ?

But we decrease count in the inlist foreach ... (Just saw it now sorry)

Radio_Group right now:
(P) selected_object
(P) selected_value
(m) register
(m) unregister
(E) value,changed

But since it works now for you, can you abond this revision?

The pkg-config file in harfbuzz is part of the upstream project (https://github.com/harfbuzz/harfbuzz/blob/master/src/harfbuzz.pc.in).
Undependend from the rest of this patch. This should never happen, if you do not have the .pc file arround, then you only installed half of harfbuzz.

I am tired of repeating myself, and i am not going to discuss it again: https://phab.enlightenment.org/T7867#138325

I am also in favor of this rfc, there is just one thing that i do not like:
toggle is a API which is not in the style of the rest of EFL, we usally only have the property, flipping this bit should be fairly easy. Additionally, (from a user pov) in most cases you do not want to flip the bit, but rather set a explicit value.

In T7893#138505, @woohyun wrote:

• Using internal hidden supper weird api, that gets randomly wrong values passed.

Can I know the name of that weird API ? I also want to check together.

efl_ui_slider_move_knob
efl_ui_slider_down_knob
efl_ui_slider_val_set
efl_ui_slider_val_fetch

It is impressive that such a high quality name passed review.

Maybe i am a bit too anxiously, but i think we want to have some boolean flag if its on the stack or heap. In some event callback to EFL_PACK_EVENT_LAYOUT_UPDATED or change event, a user *might* add another item or removes a item, which *might* change count to something below 500 or above 500 where it was not before, which means we either call free(items); when its on the stack, or we do not free it and leak the memory.

Just a site note: You can just build efl with meson and enabled examples, the example will be compiled as ./src/examples/evas-vg-json :)

I like the proposal. However, Radio_Group is a interface and needs to stay a interface, but it can inherit from Efl.Ui.Single_Selectable. My only fear here is that the single / multi_selectable interface bring again the same problem of types that we have in the pack_linear interface. We need some sort of template in order to express the types correctly. But the overall concept does look nice. Can you create a separate "RFC: ..." ticket in the "efl: api" project?

HAVE_GETPWENT is used as a gatekeeper for functions that return passwd structs. (also in the rest of EFL).

I am talking about mouse-wheel event :)

Test looks fine, i will wait on @segfaultxavi for checking out the docs.

I think i should clarify the 3ed point: The API itself is not taking any reference there, it is essentially just erroring based on this flag. Who *is* taking this ref is _efl_add_end. so this is kind of missleading.

And then he said "lets do it later"

The method that so so long here is the calculation of the focus graph, which takes insanely long in this case. However, it is questionable to me how we are going to improve that, (to be fair here, i know not a single reallife application that creates 2K buttons, and stuffs them in a box), we could create some sort of data structure like a BVB, or a quad tree, with some umbrella metric. The speedup for such an structure is however questionable since they most of the time only pay off if you query your whole set multiple times, and are most of the time more expensive for the first time than the actual calculation.

If you are eager to remove a for loop + strncpy, feel free. However, there is no reason to make that for windows only, you could also change line 198&237 to #ifdef HAVE_GETPWENT and error directly there. This will enable the optimization for any other non getpwent platform.

Wait - windows never tried before to access names, getpwnam is not available there, and it just tells the user that this is not available and returns 0. What exactly is the purpose of this patch?

@cedric but if we optimize our code with something like a module, which makes super calls direct calls, not passed through vtable. Then this results in a different behaviour. Right now i would claim that doing such a optimization is the biggest speedup vector we have, such a code would break that possibility.

@vtorri i would prefer to remove the added lines from A-B, this will then just handle the platform issue in _fetch_user_homedir and the API user is informed that the platform does not support user fetching.

No - if a user is not found, a error will be raised, and 0 is returned.

eeeehm, can we solve that outside eo ? and set a flag somewhere to skip that ? That is like killing any assertion of making optimizations later on.

I think this should probebly raise a error, and not just silently return 0.

I would like to merge this widget at the latest on the 27.07.

add multiselect radio

fix scroller bouncing

... git add accident

... git add accident

... git add accident

... git add accident

git add -p accident

git add -p accident

i think you can also just take a normal elm_test window, and set the hint_min_size to something bigger than your screen.

elm_test, my screen on my raspberry pi is quite small.

rebase

return on false

return on false

add return

Definition of ownable: A object is ownable, if we know, that the references that are taken, are not taken by someone else. A reference is taken by someone else, if parent is set. (parent always has 1 ref).
We surely cannot assert that the free references are really belonging to the user (because we do not have explicit reference handlers). Its not perfect, but its the best we can do i guess.

Sure.

I totally agree with adding Clickable to check (that will also bring it to radio). (Not sure right now why we are discussing this here, and not in T7865)

Get a window with a minsize bigger than your screen, -> maximize.

Mhm, a second thought about clickable until:
The class only really connects objects and and themes to the implementation, saying that such a util is bound to clickable is not really true, scrollable_util is also doing the same thing.
How about we create a class "Action_Connector", which contains such methods for clickable, scrollable, and whatever comes next? We would have a central place for such "connectors" ?

the point is not to access the pointer. the point is to check the pointer for correctness in the testcase.

You could also do:

once is more expressing that it is ensuring that the callback is called once, and puts that into a int flag. You can basically do the same with a void* (Which is would like to add after that, and refactor the tests of the last few weeks)

Looks good otherwise

rebase

error on mistake

error on mistake

I agree that there should be a error preventing you from doing something that is not good. I will add a helper to eo, which makes it easy to use, (or maybe can be added completly by eolian). However, such a helper will only contain a error, and never change the state or reference things of a object. Its IMO bad if we have code that just alters the references and parents to *prepare* something for you, there is one case where it might be right, others where it might be wrong. But overall the API user should have the overview (and a error if he does wrong things).

I totally agree. #2 sounds good. Some names with Bridge, Bind & Theme/Object sound good ?

Ping?

Just as a quick heads up of that widget:

• Using internal hidden supper weird api, that gets randomly wrong values passed.
• moving the key events for changing the slider does not change the value
• events are only emitted after user did interaction, not via api

Yes. Not doing this will also cut out all bindings.

rebase

forgot a single change, sorry.

scroll right now has a rect and a boolean flag for toggling the animation. With this you can say that the specified rectangle needs to be moved into the viewport. However, a user also might want to give a hint where the rectangle in the viewport wants to be (top-left ? center? top-right ?) A Position_2D with relative coordinates could be useful for that.

the mouse drags never used the step variable, slider can get values that are outside the n*step and i think that is normal ?
Like scaling something, you might want to have a step of 0.1 but still want to reach 0.95.

looks good.

Fixes back from '16 ... lovely ...

I think you want to use eolian to specify that you overwrote those methods. ?

I like the 3ed the most, it would cleanup our toplevel Efl.Ui. domain a lot.