Spec - Layout behaviour when resizing
I do not get the image, but I know what happened :) On 11 Nov 2013, at 20:08, Bahman Movaqar <Bahman@BahmanM.com> wrote:
Hi all,
Let's assume I have a window like the one in episode 2 of the tutorial. Some unexpected (from the user's perspective) behaviour happens when I manually resize the window. A snapshot is worth a thousand words (and I'm going to put two snapshots here!).
This is the fresh window that I just opened:
The same window after resizing:
So this is my understanding: When a window is resized, every Row/ColumnLayout distributes 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: 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
A button should not change height and width, unless specifically mentioned otherwise. Why ? 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 ?
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:
Ben
I'd appreciate if anyone could shed a light here; specially Benjamin the Undocumenter :-) -- Bahman Movaqar (http://BahmanM.com)
ERP Evaluation, Implementation & Deployment Consultant PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com)
On 11/11/2013 22:52, Benjamin wrote:
I do not get the image, but I know what happened :)
Oops! Corrected that.
On 11 Nov 2013, at 20:08, Bahman Movaqar <Bahman@BahmanM.com <mailto:Bahman@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?
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.
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.
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 :-) The best case I could get was a button with fixed width but a variable height. Could you please help me out a bit here? -- Bahman Movaqar (http://BahmanM.com) ERP Evaluation, Implementation & Deployment Consultant PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com)
On 12 Nov 2013, at 04:11, Bahman Movaqar <Bahman@BahmanM.com> wrote:
On 11/11/2013 22:52, Benjamin wrote:
I do not get the image, but I know what happened :)
Oops! Corrected that.
No problem :)
On 11 Nov 2013, at 20:08, Bahman Movaqar <Bahman@BahmanM.com <mailto:Bahman@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 :(
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 :)
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 :)
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. Then, each of this corners can be shifted in x and y by a _fixed_ value (in pixels) Ben
The best case I could get was a button with fixed width but a variable height. Could you please help me out a bit here?
-- Bahman Movaqar (http://BahmanM.com)
ERP Evaluation, Implementation & Deployment Consultant PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com)
On 11/12/2013 17:29, Benjamin wrote:
On 11 Nov 2013, at 20:08, Bahman Movaqar <Bahman@BahmanM.com <mailto:Bahman@BahmanM.com> <mailto:Bahman@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? 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*.
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!
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? I wonder what am I doing wrong since it has no effect whatsoever? Thanks, -- Bahman Movaqar (http://BahmanM.com) ERP Evaluation, Implementation & Deployment Consultant PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com)
Bahman Movaqar wrote:
On 11/12/2013 17:29, Benjamin wrote:
On 11 Nov 2013, at 20:08, Bahman Movaqar <Bahman@BahmanM.com <mailto:Bahman@BahmanM.com> <mailto:Bahman@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? 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*.
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!
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? I wonder what am I doing wrong since it has no effect whatsoever?
Thanks,
-- Bahman Movaqar (http://BahmanM.com)
ERP Evaluation, Implementation & Deployment Consultant PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com)
Ben On 12 Nov 2013, at 19:46, btc@openinworld.com wrote:
Bahman Movaqar wrote:
On 11/12/2013 17:29, Benjamin wrote:
On 11 Nov 2013, at 20:08, Bahman Movaqar <Bahman@BahmanM.com >>> <mailto:Bahman@BahmanM.com> <mailto:Bahman@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)
On 11/12/2013 22:58, Benjamin wrote:
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 ?
Nothing :-)
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 ?
Quoting Ben from another e-mail in the same thread: "For a single line text box, I would expect it to scroll text horizontally out of view. "
Which widget of text ?
I've tried TextInputModel so far.
This behaviour is actually Morphic behaviour, not Spec. But anyway, it can/should be fixed/improved :)
Yay!
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 ?
The same as using `add:`. I get a big fat blue button which fills up full container space and continues to do so when the container is resized :-) -- Bahman Movaqar (http://BahmanM.com) ERP Evaluation, Implementation & Deployment Consultant PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com)
Sorry for not attaching the snapshots. Here they are. On 11/11/2013 22:38, Bahman Movaqar wrote:
Hi all,
Let's assume I have a window like the one in episode 2 of the tutorial <http://bahmanm.com/blogs/spec-part-2-layout>. Some unexpected (from the user's perspective) behaviour happens when I manually resize the window. A snapshot is worth a thousand words (and I'm going to put two snapshots here!).
This is the fresh window that I just opened: Snapshot of fresh window just opened
The same window after resizing: Snapshot of the window after resizing
So this is my understanding: 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?
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. 2. A button should not change height and width, unless specifically mentioned otherwise. 3. It's not usually desirable that the spacing between radio buttons change. 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).
I'd appreciate if anyone could shed a light here; specially Benjamin the Undocumenter :-)
-- Bahman Movaqar (http://BahmanM.com) ERP Evaluation, Implementation & Deployment Consultant PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com)
participants (4)
-
Bahman Movaqar -
Benjamin -
Benjamin
-
btc＠openinworld.com