Ben
On 12 Nov 2013, at 19:46, b...@openinworld.com wrote: > Bahman Movaqar wrote: >> On 11/12/2013 17:29, Benjamin wrote: >> >>> On 11 Nov 2013, at 20:08, Bahman Movaqar <bah...@bahmanm.com >>> >> >>> <mailto:bah...@bahmanm.com> >> >>> <mailto:bah...@bahmanm.com>> wrote: >> >>> >> >>>> >> >>>> When a window is resized, every Row/ColumnLayoutdistributes the width >> >>>> and height evenly among any widget or nested layouts it contains. In >> >>>> turn, widgets try to fill as much space as possible. Therefore after >> >>>> resizing text box and button have become so huge and the space >> >>>> between the radio buttons has increased so much. >> >>>> Is that correct? >> >>> >> >>> It’s correct in the sense it is expected regarding to the layout you >> >>> use :) >> >>> >> >>>> If yes, I have a couple of points to mention: >> >>>> >> >>>> 1. A text box, specially in the case of TextModel and >> >>>> TextInputFieldModel, where it's basically a single line entry >> >>>> (ENTER is not allowed), should not change height (growing width >> >>>> is understandable and desired). The height of a text box >> >>>> (specially a single line one) should only be calculated based on >> >>>> the font family and font size. >> >>>> >> >>> TextModel is for more that one line :) >> >>> TextInputField could eventually be forced to be one line, but I think >> >>> it’s too much of a restriction. >> >> >> >> I am 100% sure I didn't tell TextInputField to accept one line. It >> >> doesn't accept ENTER and I don't understand how a "multi-line" text >> >> entry widget can work without accepting new line character :-) >> >> Yes, TextInputField wraps the text but that's doesn't count as >> >> multi-line entry :-) More importantly it is unexpected behaviour from >> >> user's PoV; I have never seen a single text entry widget wrap the text. >> >> >> >> Or maybe I'm doing something wrong? >> > >> > I do not understand sorry :( >> >> Put in other words: >> 1. The default behaviour (if there's any other behaviour) of a text box in >> Spec, doesn't accept ENTER. A multi-line text entry without ENTER doesn't >> make sense, no? What enter does then ? >> 2. The default behaviour of a Spec text box, wraps the text entered if the >> length exceeds the display length of the widget. This is very unorthodox >> and wrong *from user's perspective*. What is expected ? Which widget of text ? This behaviour is actually Morphic behaviour, not Spec. But anyway, it can/should be fixed/improved :) > I have to support point 2 above. In general terms... > For a single line text box, I would expect it to scroll text horizontally out > of view. > I would expect initially at least two lines for a wrapping text box, after > which it can be free to grow vertically as needed. > > cheers -ben >> > >> >> >> >>> >> >>>> 1. >> >>>> >> >>>> >> >>>> >> >>>> 2. A button should not change height and width, unless specifically >> >>>> mentioned otherwise. >> >>>> >> >>> Why ? >> >> >> >> Because if the button changes height/width it loses the visual element >> >> which users use to recognise buttons across a screen. Just like a >> >> single-line text entry, a button's height, if not manually set, is >> >> determined only by the font family and font size. >> >> And regarding changing the button width, I've very rarely seen >> >> applications that resize their buttons when the screen is resized. >> >> Usually people put constraints over this. I'm not stating that this >> >> definitely should be some UI framework's internal mehcanism. Perhaps a >> >> simple method like `isCalculatedSize: aBoolean` with a TRUE default is >> >> enough. >> > >> > That’s true changing the size is often not desired. >> > >> > Adding a flag can be a solution :) >> > But as it brings some more complexity in the layouting ( which is already >> > > quite too complex and too big) it was not considered until now :) >> >> Makes sense. >> >> > >> >> >> >>>> 3. It's not usually desirable that the spacing between radio buttons >> >>>> change. >> >>>> >> >>> That’s true :) >> >>> But how to know that two radio buttons are close one to the other ? >> >> >> >> Right. That's the reason radio button groups are, AFAIK, always >> >> implemented as widgets. >> > >> > Yes, but morphic do not do that :P >> > Myabe I should introduce a model for that, and have my own encapsulation :) >> >> Perfect idea. And along with some documentation please :-D >> >> > >> >> >> >>> >> >>>> 4. Usually there's a way to specify how to distribute the >> >>>> width/height between layouts and widgets inside a layout (usually >> >>>> based on a percentage). >> >>>> >> >>> There in spec as well :) >> >>> You can have a look at: >> >>> add:origin:corner:offsetOrigin:offsetCorner: >> >>> >> >> Hmm...couldn't figure out the logic. Though it seems simple when >> >> looking at the code :-) >> > >> > Here you entrer in some twilight zone :P >> > >> > add:origin:corner:offsetOrigin:offsetCorner: >> > >> > >> > This screen shows an origin in x0,y0 and a corner in x1,y1. >> > Their values are between 0 and 1, and represent a _proportional_ value of >> > the > container. >> >> By the gods! How was I supposed to know the values were supposed to be 0><1 >> !? :-) Thank you for this tip! Everybody should know that :P >> >> > >> > Then, each of this corners can be shifted in x and y by a _fixed_ value >> > (in > pixels) >> >> So basically `add: #buttonGreet origin: 0.3@0.2 corner: 0.7@0.5 >> offsetOrigin: 0@0 offsetCorner: 0@0` would add a button in a center'ish >> position within its container, right? It should do something like this yes :) >> I wonder what am I doing wrong since it has no effect whatsoever? What is the result ? Ben >> >> Thanks, >> >> -- >> Bahman Movaqar (http://BahmanM.com) >> >> ERP Evaluation, Implementation & Deployment Consultant >> PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com) >> >> > > >
