On Tue, 20 May 2014 15:50:54 +0900 Carsten Haitzler (The Rasterman)
<ras...@rasterman.com> wrote:

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

Yes, I agree with that, Elm handling of minimum sizes seems to be
almost entirely lacking or broken.  In particular I've stumbled on
entrys and naviframes seem to set their minimum width to what ever you
set the original width to, but their minimum height to zero.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.

Attachment: signature.asc
Description: PGP signature

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