On Mon, 19 May 2014 23:40:13 +0100 Andrew Williams <a...@andywilliams.me> said:

> Hi guys,
> 
> After opening this task about indow sizes in elm not respecting the 
> scale set:
> https://phab.enlightenment.org/T1263
> I realised that these are all set through evas_object_resize which 
> clearly cannot know about elm scaling.
> 
> Would there be any objection to creating an elm_win_resize or 
> elm_win_size_set method that were to apply the scaling to the values 
> beffore passing back to evas resize?
> 
> Let me know equally if I've missed something but the elm_test code is 
> all this way too.

not so simple. as daniel mentioned.. this is doable with a resize multipling by
scale... what we are currently missign in elm is 2 things.

1. a nice simple way to add extra minimum sizing to a widget. currently the
ADVICE it so make a table, put an invisible rect in the 0,0 1x1 cell ANd your
real widget in the same cell. set a min size hint on the rect and presto - it
acts as an extra "control" on the table and thus your widget (set widget to
fill/expand). you can set the min size and multiple by scaling if you want.
it'd be likely useful if this trick were formalised into a widget and/or some
utility func. a simple elc_ thing to wrap this up would work - then if it
scales the min size by scale factor or also put in finger size.

and

2. more your focus - though #1 often is related. you want a *PREFERRED* size for
an object - an initial size that is possibly bigger than min size and less than
max - somewhere in between. believe it or not we have a "request" size which is
kind of intended for exactly this. what we DON'T have is logic in elm that...

  * watches for changes in preferred size and if > 0x0, just like min size,
propagates preferred size to a parent widget.
  * that takes preferred size once it propagates to the window and on first
show actually resizes to that size
  * code that might set preferred size AND account for scaling

reality is that you have a window where some widget (or widgets) - eg the text
entry, is what you want to have at a preferred size on start... not the window
as a whole, so you really want this propagation. it requires the same calcs as
min - but providing preferred size as if it were min, then passing onto parent
etc. ... this is what we really want. problem is - we haven't done it yet. this
is the solution we want... not elm_win_reisze (that uses scaling) which is just
as much a "workaround" as evas_object_resize on the window itself :)

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    ras...@rasterman.com


------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to