Page MenuHomePhabricator

Refactoring multi button entry
Closed, ResolvedPublic

Description

Multibuttonentry is quite useful. It should become part of Efl.Ui new interface. Ideally it should have both support for view and connect. It is an interesting object as it is able to connect to a list or array of property on a data model. At the same time it can use a second model to fill the view for the autocompletion.

cedric created this task.Apr 4 2017, 3:46 PM
cedric assigned this task to CHAN.
cedric added subscribers: jpeg, woohyun.
cedric raised the priority of this task from TODO to High.Jul 10 2017, 2:24 PM
CHAN added a comment.Aug 23 2017, 3:33 AM

@cedric @jpeg @Jaehyun_Cho @woohyun

Hello all.
I would like to ask you guys about Multibuttonentry.

As you guys already know, The MBE widget has been created to support tizen UX.

Previously, the MBE UX like below.

The mbe items and entry inside internal box of mbe.
And user input something on entry here the item will be append.

But that kindda UX is not using anymore for sure.

Now the UX like below.

The mbe items append inside box.
entry separate up with them.
Current MBE can't suppor this, so the application create a mbe and a entry with using item append APIs to support this.

Not only tizen side also in the upstream.
We don't use previouse mbe.

So i recommand we should let it legacy mbe there. and create a brand new mbe like below hierarchy.

I think MBE is extension some features on entry.
Main feature is get a input on entry. and create a item then append internal box.
This is a main concept of MBE.

So i Inherited entry. then make a class which has two part (entry area, box area)
It can support current mbe UX.

If we need the previouse MBE can be MBE_1 here. or other requeset can be MBE_2

Anyway any suggestion? or opinion here?

jpeg added a comment.Aug 23 2017, 6:46 PM

You mean MBE 1 is like legacy UX and MBE 2 is like the new UX? And those are two subclasses of MBE?

CHAN added a comment.Aug 23 2017, 10:21 PM

@jpeg Thanks for fast feedback here.

No no please ignore about MBE_1 MBE_2.
I meant that if we need something other concept of MBE in the future. that can be MBE_1 or something.

Just focus on 2 things for this.

  1. inherit entry.
  2. new MBE.

Sorry about that confusing. :}

jpeg added a subscriber: herdsman.Aug 27 2017, 10:50 PM
CHAN added a comment.EditedAug 29 2017, 3:44 AM

Summary of meething about MBE.

  1. We should not inherit entry, we had better to use efl_composite_attach to use all of the efl_ui_text methods in MBE without any additional work(override).
  1. Two different type of MBE will combine for one class. we will seperate the logic of both by style.

Now i will begin implementation.

CHAN added a subscriber: herb.EditedMar 12 2018, 5:28 AM

@cedric

Hello.

I would like to ask your opinion about MBE's item.

Now the MBE item type is Elm_Object_Item. But i heard that the type will not taking in efl interface.

As a result of the discussion with (@woohyun @herb ) about this , there seem to be two ways.

The first way is using index for it.

MBE user can add items using API, as well as the MBE creates item internally.

So we dont give any type of defined things. just return index for item and gets index to handle it.

For this, We need to add some of methods which supported elm_object_XXX things.

The following API is supposed to be added when considering mbe item usability. item_text_set/get().

we can increase it when gets a request. :)

The callbacks about item provides using Efl_Event's info of callback function.

The second ways is that just changed from Elm_Object_Item to Efl_Ui_Button.

Create a class "Efl.Multibuttonentry.Item(Efl.Ui.Button)".

Give the Button Eo to user to handle it.

But, There is a problem that the user can use all APIs which does not work because of the internal logic, like content_set(), efl_gfx_XXX APIs. This ways looks clear though...

What do you think about the way of supprot MBE item? Plase give your opinion.

Simple summary in C style.

  1. efl_ui_multibuttonentry_item_append(mbe, 1, "test");

    efl_ui_multibuttonetnry_item_text_set(mbe, 1, "change");
  1. Eo *mbe_it = efl_ui_multibuttonentry_item_append(mbe, "test");

    efl_text_set(mbe_it, "change");

Thank you.

@CHAN
I think below are correct. Please check whether I'm wrong.

efl_ui_multibuttonentry_item_append(mbe, 1, "test"); -> efl_ui_multibuttonentry_item_append(obj, text);
efl_ui_multibuttonetnry_item_text_set(mbe, 1, "change"); -> efl_ui_multibuttonetnry_item_text_set(obj, text, index);

@cedric
We have discussed about the concept for items in MBE.
And we concluded that this MBE is for the simple use. That is, we will add new MBE if we want to apply MVVM later.

This is because when we consider the ambiguous future of MBE (with MVVM) - following prolbems could be happened.

  1. There can be confliction between "simple item appending" and "MVVM", if these are used together in one MBE object.
  2. MBE class should be implemented differently to cover both cases.

If we are thinking wrong, please share your idea :)
Thank you.

@CHAN
I think below are correct. Please check whether I'm wrong.

efl_ui_multibuttonentry_item_append(mbe, 1, "test"); -> efl_ui_multibuttonentry_item_append(obj, text);
efl_ui_multibuttonetnry_item_text_set(mbe, 1, "change"); -> efl_ui_multibuttonetnry_item_text_set(obj, text, index);

IMHO, efl_ui_multibuttonetnry_item_text_set(mbe, 1, "change"); is better.
i.e. efl_ui_multibuttonetnry_item_text_set(obj, index, text) because the object index means like obj[i].text = "ABCD";
So I think keeping the order is better.

I agree we should focus on making it a simple MBE (meaning not handling MVVM nor vast amount of content). Now, I have been wondering if we could not use the pack interface to add new item and have a specific expected item type that would be the only type accepted inside the MBE. This is kind of with item, except that the item will be real object and that they will be build outside of the MBE (This would give more freedom for customisation).

I need to be look at current MBE, but I think that MBE does create some object itself automatically, no ? If so, we have to either add an event that would expect a call to add an item to the MBE be done there or we register a factory type of object that would automatically do the conversion. I know that you guys are not at ease with factory design pattern, so if the event is good enough, we can start with that and add factory support later as they are orthogonal and won't impact the API.

@CHAN
I think below are correct. Please check whether I'm wrong.

efl_ui_multibuttonentry_item_append(mbe, 1, "test"); -> efl_ui_multibuttonentry_item_append(obj, text);
efl_ui_multibuttonetnry_item_text_set(mbe, 1, "change"); -> efl_ui_multibuttonetnry_item_text_set(obj, text, index);

IMHO, efl_ui_multibuttonetnry_item_text_set(mbe, 1, "change"); is better.
i.e. efl_ui_multibuttonetnry_item_text_set(obj, index, text) because the object index means like obj[i].text = "ABCD";
So I think keeping the order is better.

@Jaehyun_Cho
I've refered the definition of pack_at in Efl.Ui.Pack interface.
(i.e. pack_at(obj, sobj, index)

If MBE case should be cared differently, you could be right - but, I do think keeping consistency would be better.
How do you think about this ?

@Jaehyun_Cho
I've refered the definition of pack_at in Efl.Ui.Pack interface.
(i.e. pack_at(obj, sobj, index)

If MBE case should be cared differently, you could be right - but, I do think keeping consistency would be better.
How do you think about this ?

@woohyun
I think that the actions are slightly different between pack_at() and item_text_set().
Because pack_at() newly pushes an object into some place of the widget and item_text_set() gets an object, which is already pushed into some place of the widget, and writes/replaces text on it.

This comment was removed by woohyun.

@woohyun
I think that the actions are slightly different between pack_at() and item_text_set().
Because pack_at() newly pushes an object into some place of the widget and item_text_set() gets an object, which is already pushed into some place of the widget, and writes/replaces text on it.

Yes, this is why I don't want item_text_set(). The idea is to have user do pack_at of a new object that would provide a text interface.

woohyun added a comment.EditedMar 13 2018, 11:30 PM

I agree we should focus on making it a simple MBE (meaning not handling MVVM nor vast amount of content). Now, I have been wondering if we could not use the pack interface to add new item and have a specific expected item type that would be the only type accepted inside the MBE. This is kind of with item, except that the item will be real object and that they will be build outside of the MBE (This would give more freedom for customisation).

I need to be look at current MBE, but I think that MBE does create some object itself automatically, no ? If so, we have to either add an event that would expect a call to add an item to the MBE be done there or we register a factory type of object that would automatically do the conversion. I know that you guys are not at ease with factory design pattern, so if the event is good enough, we can start with that and add factory support later as they are orthogonal and won't impact the API.

Honestly, I don't think MBE's item does not need freedom because it have got only text.
So did WooChan, and he suggested the first way without any new class for the item.

Ok. if we need to handle the item outside MBE, there could be two ways as you mentioned.

  1. Create button like class and add event to give its text change to MBE.
    • UI object should be created by Item Class and MBE will do locate and resize the UI object.
    • Good : There can be UX freedom.
    • Bad : What should be happened when developers try to insert Efl.Ui.Button, ?
  1. Apply factory design
    • As you talked I'm not much familiar with this design. So, I want to ask .... (1) Factory should be created per item ? or Only one factory will be enough one MBE object ? If it's created per item .. then what is difference with Elm_Object_Item .. ? If it's created per object (like efl.ui.list) .. then how could we set text (or icon) to the specific item ? (2) If there will be a factory for MBE, then current efl.ui.factory interface could not be used because its for model connection. Then, I think current efl.ui.factory changes its name to efl.ui.model_factory... or something like this. How do you think about this ?

Thank you ! :)

CHAN added a comment.Mar 15 2018, 6:09 AM

@cedric @woohyun @Jaehyun_Cho

Thank you for giving ur opinion here.

I think the freedom and customization of the items are not particularly necessary.

The basic UX of the MBE can be divided into items of the same style listed by the user's API call and items added using an internal entry.
We dont have much work to change item properties.

The current MBE implementation is only item creation internally, and only the simple UX using the item is satisfied.
So I think that the implementation of creating an item from the outside and packing it in the MBE will give the user more work and difficulty.
Let's make it simple with minimal set.

I don't know about the factory well, but there are no cases where a huge number of items are made on the MBE and there will not be many item styles supported.
It seems to be more damaging than advantage.

I would appreciate it if you give me information about it with your opinions.

It is not just about customization of the UX, but also keeping the same API as other widget. If we have a text_set and an item_text_set, we are starting to fail that goal. And it could become worse if we wanted to support more text feature. This is why we need to expose the object itself. The factory pattern design is just to automate the creation of the widget from the text typed in the entry part.

API that would make sense, in my opinion, on the MBE directly are for example a function that return Eina_Iterator<string> which would internally walk over all the packed object and do a efl_text_get.

CHAN added a comment.EditedMar 27 2018, 12:47 AM

@cedric Thanks for giving opinion.

In summary our dicussion, there are three options can be applied to support MBE item feature.
The following codes will use for the very simple MBE. Let's choose.

1. Create item class to handle item object instance.

Void main()
{
	Eo *mbe = efl_add(EFL_UI_MULTIBUTTONENTRY_CLASS, parent,
                          efl_event_callback_add(efl_added, EFL_UI_MULTIBUTTONENTRY_EVENT_ITEM_CLICKED, mbe_item_clicked_cb, NULL),
                          Eo *item = efl_ui_multibuttonentry_item_append(efl_added, "it1"),
                          efl_ui_multibuttonentry_item_insert_after(efl_added, item,"it2"),
			  efl_ui_multibuttonentry_item_append(efl_added, "it3"),
	                  efl_text_set(item, "it4"));
}

static void
mbe_item_clicked_cb(void *data EINA_UNUSED, const Efl_Event *ev)
{
	Eo *item = ev->info;
	printf("item text = %s", efl_text_get(item));
}

2. Using index

Void main()
{
	Eo *mbe = efl_add(EFL_UI_MULTIBUTTONENTRY_CLASS, parent,
                          efl_event_callback_add(efl_added, EFL_UI_MULTIBUTTONENTRY_EVENT_ITEM_CLICKED, mbe_item_clicked_cb, NULL),
                          efl_ui_multibuttonentry_item_append(efl_added, "it1"),
			  efl_ui_multibuttonentry_item_append(efl_added, "it3"),
                          efl_ui_multibuttonentry_item_insert_after(efl_added, 1,"it2"),
	                  efl_ui_multibuttonentry_item_text_set(1, "it4"));
}

static void
mbe_item_clicked_cb(void *data EINA_UNUSED, const Efl_Event *ev)
{
	int it_idx = ev->info;
	printf("item text = %s", efl_ui_multibuttonentry_item_text_get(id_idx));
}

3. Use factory (Model connect or User manual)

Void main()
{
        //Code will be below shape whether model use or not.

	Efl_Ui_Multibuttonentry_Factory *factory =  efl_add(EFL_UI_MULTIBUTTONENTRY_FACTORY_CLASS, parent);
	
	//Create model or User manual.
	model = efl_add_ref(EFL_MODEL_ITEM_CLASS, NULL);
	//Make model here.

	efl_ui_model_connect(factory, "elm.text", "it_text");


	Eo *mbe = efl_add(EFL_UI_MULTIBUTTONENTRY_CLASS, parent,
			  //Model property change callback add here?
                          efl_event_callback_add(efl_added, EFL_UI_MULTIBUTTONENTRY_EVENT_ITEM_CLICKED, mbe_item_clicked_cb, NULL),
                          efl_ui_multibuttonentry_factory_set(efl_added, factory);
                          //Optional.		  
                          efl_ui_view_model_set(efl_added, model));
}
	
static void
mbe_item_clicked_cb(void *data EINA_UNUSED, const Efl_Event *ev)
{
	Eo *item = ev->info;
	printf("item text = %s", efl_text_gett(item));
}

third way code is not clear yet please consider it. But it needs to create factory and connect model or user handle it manually.
As we already talk about each things, I thought the second way was the best, but it seems to be inconsistent when using the API compared to other widgets.

So i think the first way is best for this.

What do you guys think?

I do not like [1] and [2] as they clearly repeat the mistake of our past API. I believe that [3] is to complex at the moment. What if we were following the same pattern as with the tab pager ? The idea would be to pack button entry, like we do pack tab page. This can easily be merged with the factory design and all without MVVM pattern. It should be simple to get that implemented, what do you think ?

CHAN added a comment.Mar 28 2018, 3:38 AM

@cedric I agree with that.

Once we have an implementation similar to a tab pager, it looks good it will not be a problem and simple, but it might be a problem if we apply the factory design later.

Efl.Ui.Multibuttonentry mbe = new Efl.Ui.Multibuttonentry();
Efl.Ui.Multibuttonentry.Item it1 = new Efl.Ui.Multibuttonentry.Item();
it1.text_set("abc");
mbe.pack_end(it1);

But after the factory design apply, user can add "def", "ghi" items by model.
Then we support two ways to add items there. is it allowed? The model may not know about "abc" in this case.

Anyway i think it deserve to apply factory pattern, and it is almost same discuss with efl_ui_list things with @SanghyeonLee
Let's talk to one channel, i will join the mail and then make a desicion about it same way with list.

I would say that as soon as a model will be set all the previously packed object should be unrefed and future call to the pack API should fail.

@cedric
I think we need to think about the pros anc cons for each suggestion.

1. MBE class (Item UI) + MBE_ITEM class
Item's UI should be created in MBE because we need to consider when the item's UI needs to be created by entry input.

[GOOD]
It's simple to use

[BAD]
No UX extension because item's UI would be created inside MBE.
Only one MBE_ITEM class will exist for the specific MBE class.

Then, Why do we need to create separate item class of MBE ?
(I'm sure no application developer will understand the reason of this)
Supporting item_append("text") in MBE would be intuitive for the app developers.

Plus, I really don't like the concept that there would be priorities between item packing and model setting.
Why do we need to teach this thing to app developers ?

2. MBE class + MBE_ITEM class (Item UI)
By applying factory pattern to MBE_ITEM class, ui_get method would be supplied for MBE class.

[GOOD]
Good to support UX extesion. There can be variety of MBE_ITEM classes. (But it's impossible !!!! Let's check BAD below.)

[BAD]
This is impossible if we will not limit only one MBE_ITEM class would be used for the specific MBE class.
That's because we can not decide what kind of item UI should be created when entry input happened.

3. MBE class + MBE_FACTORY class
For the simple use of MBE, this MBE_FACTORY class should not be something that has relation with model.
We need to create simple factory for this.
Later, after MVVM is fixed well, we can make new factory such as MBE_MODEL_FACTORY.

[GOOD]
Good to support UX extesion by supporting different MBE_FACTORY classes.
Plus, there would be no problem when we support MVVM based factory later.

[BAD]
Not simple to use.

4. Only MBE class
MBE will support item_append (or item_insert) by itself and getting information from an item would be done by index.

[GOOD]
Simple to use.

[BAD]
Index based APIs could break consistency with other UI classes.
Plus, we may need to create new MBE class for MVVM support later.

For me, [3] and [4] look ok.
How do you think about my opinion ?

I think you have summarized every option quite well. I do just have a question about [2] and why you think that this is impossible to decide what kind of item UI should be created when entry input happened. I would have expected that the UI item would be choosen depending on the input and some global state.

Also I am thinking of another variant that I can see like :
MBE class + MBE item class (child of button class) instantiation on input parsed event.

The idea would be that when you press enter an event is fired with the inputed text as part of the event information. From there the user can decide to filter it out, or create any object that would be of MBE item class. The MBE would get back the text by doing text_get on the MBE item that get packed in. Allowing for changing the text easily if scenario require it.

On top of this system, a direct factory can be added that would when set on the MBE, setup an event handler that does the above automatically (Factory with no connection with model at this point for sure).

Depending on which case is the most likely use case, we would either initialize the MBE with a default factory that does provide a default MBE item class or not. If it is initialized with a default factory, if the user want full control, he can just set the factory to NULL and if he want to replace it, he can just set it to something different.

I think that looks like a merge of [1] and [3]. Offering likely maximum flexibility with less code complexity for us and likely a possible evolution path for introduction of MVVM interface later. What do you think ?

woohyun added a comment.EditedMar 29 2018, 9:22 PM

I think you have summarized every option quite well. I do just have a question about [2] and why you think that this is impossible to decide what kind of item UI should be created when entry input happened. I would have expected that the UI item would be choosen depending on the input and some global state.

You mean that an application needs to choose specific item UI for each entry input. Am I right ?
I don't think application developers may want to do this by themselves.
This should be the one of major features of MBE.

Also I am thinking of another variant that I can see like :
MBE class + MBE item class (child of button class) instantiation on input parsed event.

The idea would be that when you press enter an event is fired with the inputed text as part of the event information. From there the user can decide to filter it out, or create any object that would be of MBE item class. The MBE would get back the text by doing text_get on the MBE item that get packed in. Allowing for changing the text easily if scenario require it.

With this idea, we can support the concept of "MBE class + MBE_ITEM(Item UI)".
But, as I talked before, I am sure no application may want to add an item everytime entry input is happened.
Plus, if this work would be done by application side, MBE is only a set of buttons. Nothing else.

On top of this system, a direct factory can be added that would when set on the MBE, setup an event handler that does the above automatically (Factory with no connection with model at this point for sure).

Depending on which case is the most likely use case, we would either initialize the MBE with a default factory that does provide a default MBE item class or not. If it is initialized with a default factory, if the user want full control, he can just set the factory to NULL and if he want to replace it, he can just set it to something different.

I think that looks like a merge of [1] and [3]. Offering likely maximum flexibility with less code complexity for us and likely a possible evolution path for introduction of MVVM interface later. What do you think ?

When we talk about this concept, we need to define the roles for MBE, MBE_FACTORY, and MBE_ITEM.
Please check my comment below.

woohyun added a comment.EditedMar 29 2018, 10:03 PM

@cedric

Ok. Let's try to merge [1] and [3]....

Efl.Ui.MBE mbe = new .. ();
Efl.Ui.MBE_Factory fac = new ...();  // I know that defaut factory could be initiated inside MBE. 
                                     // This is just for thinking of the structure of whole MBE.
mbe.factory_set(fac);  // Don't be serious with this :)

Efl.Ui.MBE_Item_1Text it1 = new ... ();
it1.text.text_set("ABC");
mbe.pack_begin(it1);

Efl.Ui.MBE_Item_2Text it2 = new ... ();
it1.text1.text_set("ABC");
it1.text2.text_set("DEF");
mbe.pack_begin(it2);

If MBE_Factory and MBE_Item classes don't have clear definition of their role,
application developers could not imagine well what would be happened with the code above.

1. If MBE_Factory has a role of deciding item UI
For example, MBE_Factory supports item UI with only one text, then "mbe.pack_begin(it2)" can give two results.
(Honestly, I think the both are ambiguous)

  1. Packing a button with "ABC" ("DEF" would not be shown)
  2. Ignoring this packing (if we limit that a factory can work only with specific set of MBE_Item classes)

2. If MBE_Factory does not have a role of deciding item UI
I don't know what would be the roles of MBE_Factory except this feature.
Anyway... then entry input problem would be happened again.
That is, application developers should do something(selecting proper Item UI, and insert it to MBE) everytime entry input is happened.

So, I cannot know what can be the benefit from merging [1] and [3].
With this concept, if we will describe the usage like below ..... then, we can not say "EFL is easy to use".

  • "When you use MBE_Factory_Default class, you can use only MBE_Item_Text1 and MBE_ITem_Text1_Icon1".
  • "When you use MBE_Factory_2Text class, you can use only MBE_Item_Text2 and MBE_ITem_Text2_Icon1".

IMHO, I can think of only two concepts.

  1. MBE supports item_append method by itself
    • There will be no Item UI extension. We need to create new MBE class for supporting different Item UI.
  2. MBE_Factory supports item_append method by itself
    • Different factories can support differnt Item UIs, and later we can support MVVM based factory together.
    • But there would be no default MBE_Factory which would be initiated inside MBE.
    • That is, an application needs to set factory to use MBE.

If you think MBE_Item is necessary, please explain the benefits of supporting it.
For me, it only gives the confusion.

I think I finally understand your concern and what you are talking about. If so, I am so sorry to not have understand that earlier. You question is not about the factory or the event, not even about how the item is created, but how do you initialize the MBE in a simple way. I think I squizzed a quick comment earlier on about maybe having a property on the MBE that would get the strings of the button by iterating over them and doing text.get. But thinking now more about it with the previous discussion going on, I think that wouldn't do if we want to support multiple style. We need something more versatyle.

Maybe we can go with the following :

  • add a values @property on the MBE that you can set/get an array of Eina_Value from
  • add a value @property on the MBE Item that you can set/get an Eina_Value from

When the values is set on the MBE, it does trigger an event for each of the entry in the array with the Eina_Value attached. It would be the same event for when someone type a new entry and the new entry will become a simple Eina_Value with just one text entry inside. When a factory is attached, it obviously is the same event that trigger the call to the factory. The factory would then get the same Eina_Value and return a new item out of it that is packed at the end of the MBE.

When a values get is requested on the MBE, it will just iterate over all the item packed in and call value get from them to build an Eina_Array out of it and return it to the caller.

I am not super happy on this idea, and we might find some possible improvement. Especially for C. In JS, it will look nice like :

mbe.values = [ "toto", "titi", "tata" ];

We might want to add some helper in C to help generating this array. Maybe a vvalues variant that work with variadic parameters (not in the .eo files, just in the .h file, explicitely for C). I do not know how this would look like in C#. @felipealmeida , do you have some suggestion here ?

CHAN added a comment.Apr 2 2018, 11:07 PM

Thank you for your good feedback. @cedric

The use of array looks good though, There is something I want to ask you.

  1. Is there any way the event can be triggered on the MBE side when the user directly modifies the eina_array property? Please let me know if there is a way to monitor the eina_array property that will be used.

    There seems to be no way to come up with anything to me now... So if then... Do user have to call mbe.values with a new array each time user add the contents of array? Or does it provide a method like update() to synchronize the modifications in the array?
  1. If there is no way to monitor eina_array, does user need to get an eina_array and update it on every event? If so, it does not seem to be much different from the existing way of item_append or text_append.
  1. The property is where you set a new Eina_Array. Indeed, the user has to call with a new array (Or it could be a @const one meaning, it stays owned by the user).

The idea at first would be on set, to destroy all the past object and emit an event for each item in the array. There is possibility to optimize this process by comparing the existing object with the new value, but I don't think we have time for this.

  1. The user doesn't need to maintain the array on his side. He can just ask a new one from the mbe.values.get function whenever he need it. The main difference with item_append/text_append is that it maintain the use of common interfaces as much as possible and use also normal object instead of item.
CHAN added a comment.Apr 4 2018, 4:48 AM

It is a good opinion.

It seems to be able to solve many of the problems we talked about.

There is no specific property and method specification yet, but the implementation seems to be fine.

Should I start with a C implementation by specifying the eo file specification with the following basic concept?

const char * text [] = {"a", "b", "c"};
efl_ui_multibuttonentry_value_set (mbe, text);

Eina_Array * items = efl_ui_multibuttonentry_value_get (mbe);
cedric added a comment.Apr 4 2018, 9:04 AM

Looks good to me !

CHAN added a comment.Apr 5 2018, 6:57 AM

@cedric

there is something I want to check.

In the code above, value_set() receives 'char *' and value_get() returns Eina_Array ... Is this the right concept what you want?

Can I understand and proceed with the form of sending and receiving Eina_Array?

@cedric

I'm also confused with the concept you talked.
If we want to make "value" as a property for efl_ui_mbe, it should have specific data type.

That is, it should be char ** or Eina_Array.

Or, we need to support two different methods such as -

  • void mbe_value_set(obj, char **)
  • Eina_Array mbe_value_get(obj)

We want to know your concrete idea on this.

cedric added a comment.Apr 8 2018, 7:50 PM

oh sorry, I didn't pay enough attention. It should be mbe.values_{set,get} with an Eina_Array of Eina_Value or char* whatever make most sense (I feel Eina_Value will be more versatile). And for item we have item.value_{set,get} with either Eina_Value or char* to match the need of the mbe.

@cedric
Ok. I got it.

@CHAN
If you don't have any objection on @cedric 's opinion, please go with above concept we have discussed.

zmike edited projects, added Restricted Project; removed efl.Jun 11 2018, 6:54 AM
zmike edited projects, added efl: widgets; removed Restricted Project.Jun 11 2018, 8:15 AM
zmike added a subscriber: zmike.

A #Goal ticket should not be set to a milestone.

CHAN closed this task as Resolved.Jul 16 2018, 3:53 AM

efl_ui_tags has been created.

zmike edited projects, added efl: mvvm, efl (efl-1.22); removed Restricted Project.Jan 9 2019, 12:09 PM