My comment are in-lined. On Tue, 2011-02-08 at 09:28 +0000, ChunEon Park wrote: > Hi Tom, sorry for replying lately. It's ok. :) > > > The reason, a ctxpopup is openning really far from where user click, > is... > > currently it is intended to be affected by finger size. > > Yes. I realized just before that fact - it's not good concept as the > desktop widget > > since the original concept of ctxpopup is for the touch screen > environment. > > (It means when user touches any point on the screen then ctxpopup will > be showed up far from the user's finger.) > > > > I need to think how to meet both two cases. > > (I think ctxpopup needs to provide an another API for that finger > size > or could you please adivse for it?)
As we talked about in IRC, I don't think the finger size in account in this case is really wanted, not even on touch-screens. On the desktop it's ok, we should just define finger size to be 1 (or some other very small value) anyway (I hope it won't break anything) the problem is that I don't see how it helps touch screen users. This open on a click so the user already picks up his finger after clicking, so it won't be hidden by it. I think it's more consistent and as expected to just open when the user clicks. As you can see, the first time I saw this I sad, "wth, weird bug" and not "omg what a cool feature" and I think users will respond the same way. > > > > Arrow issue.. I really don't know what arrow issue you mean... > > Could you explain again? Was just referring to the removal of the diagonal arrows, no biggie. > > > > and the patch 003... > > It's my fault. > > Maybe I shouldn't use the elm_object_scroll_freeze/hold APIs. > > It affects parent's scroller so it causes problems. > > (I really wonder why elm_object_scroller_freeze/hold affect their own > parent scroller?) > > Maybe, ctxpopup should provide another scroller enable/disable APIs > additionally. I'm not sure I quite understand what you are trying to do. > And the last one. elm_list ! > > I understood why we reuse the exist widgets and avoid duplicated > functions. > > I will do that if it can be done. > > I thought elm_list can be impossible to meet the ctxpopup > fucntionality. > > Before my patch, elm_ctxpopup has a problem about it's sizing. > > and the first motive widget of ctxpopup is elm_menu (it does not > use elm_list.). > > > > Anyway, The problem is, > > Ctxpopup should know it's list size to position. > > Sametime, list should know it's items sizes to determine the > ctxpopup's size. > > Once I can know the list's total item size, then i can determine > ctxpopup size and position > > or readjust the list size additionally. I concerned about that I > dont' know the size of list when determine the position. > > > > Currently ctxpopup calculates it's box size first then finds available > space from the it's position. > > If ctxpopup uses the list, then it dont' know the size of the total > items. maybe... > Just add a "content size get" function to the list. elm/els scroller provide it anyway, so just passing it forward outside of list will be very easy to implement, and if you find this API useful, I don't see any reason why not to add it. It's actually nice because it can help people (just like in this case) choose a good size for the list. I don't think we should re-implement list. This will introduce bugs, inconsistencies and code bloat. > > Anyway, Yes, this time I need to check the possibility of using of > elm_list again. > > (I do it first when I am free, then try it upstreamed if it can be > done ) Please do. I think this will make everything a lot simpler. Generally speaking it's better to adjust existing code to do more, than adding more code that does the same. > > > > I hope you consider that elm_list can cover the above case > > > > Anyway, I appreciate you for concerning this widget. :) You are the one that made it cool, I wouldn't have cared about this widget otherwise. -- Tom. ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
