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) 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
