On 28/05/15 08:30, SHILPA ONKAR SINGH wrote: > Hi Daniel, > > Good Idea, but it will still be calling an external function in the middle of > menu call right? > The function which is registered by application using menu item provider API. > but still, this idea is good and methodical. > Now question is, should we go for menu_provider_append or menu_provider_set > API? > (giving user an option of appending multiple functions or single function) > > + let me clearly state the use case again and why I wanted longpressed to be > sent before. > longpressed would place the cursor on the word and that would give me the > word and according to word I > would append the items in menu. > > Now with current solution or context,open signal sending solution, I have to > create a custom cursor, place it on location of mouse down, get the word and > decide the menu items. (logic became a little complex). > (because cursor is placed on the word were longpressed happened but cursor is > not placed on the word where right click happened) >
The problem with the menu provider idea is that it's not as easily bindable (bindings) as a callback. The callback is good in that regard. I don't object to this signal, I just would like to see what others think about the flow (like Daniel's comments). -- Tom. > Best Regards, > Shilpa Singh > > > > ------- Original Message ------- > Sender : Daniel Hirt<[email protected]> Engineer/SRIL-Advanced R&D > Lab/Samsung Electronics > Date : May 28, 2015 15:13 (GMT+09:00) > Title : Re: [E-devel] Elm_Entry context menu, dynamic items addition > > Hello, > I am guessing that https://phab.enlightenment.org/D2580 is one of the > proposed solutions, right? > > I like the general idea, but I don't like the call for some unknown > function in the middle of _menu_call. > > As hinted in the revision comments, I too believe that context_menu > should be modified a bit to treat this better. Off the top of my head, > maybe add some kind menu_item_provider logic and api, so the > context_menu will support both static and dynamic types of menu items. > > What do you think? > > -- > Danny (herdsman). > > On 05/27/2015 03:14 PM, SHILPA ONKAR SINGH wrote: >> >> Hi All, >> Currently in elm_entry context menu code, whenever we append menu items >> to >> entry they are statically appended, >> and we can see those items only after menu is re-created. >> Assume this use case, application appends items to menu in "longpressed" >> callback, say based on text content(cursor >> located on what text), In this kind of use case, the menu items will not >> be >> seen (as menu is created and shown already) and >> menu items will be seen only on second longpress but the second longpress >> can be anywhere and if decision of appending items in to menu is >> dynamically >> decided based on text content then we can never really show the desired >> menu >> items. >> >> (Specific usecase: Say we are appending translation or synonym of the >> word >> on which long press was done in to context menu) >> >> our fix was to send "longpressed" signal before creating context menu so >> that application can append menu items based on word on which longpress >> is >> done. >> >> As the above solution is too specific to longpress scenario, Tom >> suggested >> to send a signal just before creating menu and append the items in its >> callback, this method works well ) >> >> >> but can we handle this in a better way? looking for suggestions. One way >> might be to directly append items to menu when menu item add is called >> instead of just storing it and keeping it and using it >> >> on next menu create. >> Best Regards, >> Shilpa Singh >> >> [cid:[email protected]] >> >> >> [SeenTimeChecker?do=502122e85cbba61abf37f499cbab7d53fb80820eafb9cad8733afbaf >> >> 10963357ba777c355c197185c465c2cf80a2b7ef9aba4bb3b2b5ca43ddd7e184e0604d958075 >> b6b33f32d245b7f8aafe245478a5f1d21d5ebee74427cf878f9a26ce15a0] >> >> >> >> ------------------------------------------------------------------------------ >> >> >> >> _______________________________________________ >> enlightenment-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >> > > ------------------------------------------------------------------------------ > _______________________________________________ > enlightenment-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > ------------------------------------------------------------------------------ > _______________________________________________ > enlightenment-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
