On Fri, 11 Feb 2011 19:38:00 +0530 Rajeev Ranjan <rajee...@samsung.com> said:
> 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 if the application does - it's wrong. it should never do this to ANY elm widget. if another widget does (no elm widgets do this - please show me an example that does - other than the widget setting its OWN min size) then this is wrong too. so any problems as a result are due to badly behaved apps. > 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 - > and well edje will just respect whatever min and max size are set, but it wont go change it. > 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. well the app can do that manually d use boxes and weight and other packing things to do that - but if it is doing it manually - it should read/track and RESPECT the min and max size set - but not go modify it. > 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. no. minimum size is STILL minimum size. so is maximum. it is the PARENTS job to resize the child widget based on these properties (respect them) but not to go modify them. there is another property called request size - this size is a "preferred useful size". right now it basically isnt being used by elm. unless what you are after is the weight and align properties. weight is used to know how much to expand, if to expand at all beyond minimum size (0 is dont expand - anything bigger is expand - and is relative to other elements set to expand). and align is used to align an object within its expanded area or if -1, it means "fill the expanded area" even if expanded area IS the minimum size. > 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. see above. :) > 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 > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ 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
