Hello all, This is regarding the auto-resizing of some of the elementary widgets when their content get modified. For example, in case of elm_button when we modify the text of the button then the button size gets changed. This happens in this widget by resetting the min size hint of the widget based on edje calculated size insize function "_sizing_eval()". But sometimes even application/another widget using elm_button may set the min size hint for the button widget which gets over-written in this function resulting to no effect for the hint set by application. If we swallow the button in an edc group then there is no issue as edje will keep reinforcing the size on it however if we place the button at some location/alignment and set the min hint size for this(without explicitly resizing it) then the size of button will be the same as the min size hint set and will change based on the text length which may not be the desired behavior in some cases and the application may want to set the size of the button based on some logic suited to the application, say half/one-third of the avaliable width.
IMHO, we can have an API, say elm_object_autoexpand_set(<Evas_Object*>obj, <Eina_Boolean>EINA_TRUE). Based on the second parameter we can compare the current min size of the widget and edje calculated minimum size in function "_sizing_eval()". If the second paramer be true, then we can simply reset the minimum size to edje calculated minimum size ELSE we can see if the current min size is greater than the edje calculated minimum size, in which case we won't reset it else we will. Such kind of requirement is not limited to elm_button and may be needed for other widgets too, hence I am proposing the change at elm_widget level. Please let me know your opinion on this proposal. Thank You. Regards, Rajeev ------------------------------------------------------------------------------ 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
