Ticket #6137 (new enhancement)

Opened 3 years ago

Last modified 8 months ago

Min-Max limits for component width/height

Reported by: Joonas Lehtinen Owned by: ticketmaster
Priority: normal Milestone:
Component: Core Framework Version: 6.4.8
Keywords: Cc:
Depends on:
Verified: no
Pro Account: Vote for Feature

Description (last modified by Joonas Lehtinen) (diff)

For more flexible automatic layouts min-max sizing is sometimes needed. See  http://cappuccino.org/learn/tutorials/automatic-layout/ for a nice example implemented by a competitor.

We should create LimitedSizeable interface extends Sizeable that includes:

  • float getMinWidth()
  • setMinWidth(String)
  • setMinWidth(float, int unit)
  • int getMinWidthUnits()
  • setMinWidthUnits(int unit)
  • float getMinHeight()
  • setMinHeight(String)
  • setMinHeight(float, int unit)
  • int getMinHeightUnits()
  • setMinHeightUnits(int unit)
  • float getMaxWidth()
  • setMaxWidth(String)
  • setMaxWidth(float, int unit)
  • int getMaxWidthUnits()
  • setMaxWidthUnits(int unit)
  • float getMaxHeight()
  • setMaxHeight(String)
  • setMaxHeight(float, int unit)
  • int getMaxHeightUnits()
  • setMaxHeightUnits(int unit)

LimitedSizeable interface should be implemented by all classes that implement Sizeable today.

Change History

comment:1 Changed 3 years ago by Jouni Koivuviita

Why limit the API to pixels only and not allow other fixed units, like centimeters?

comment:2 follow-up: ↓ 3 Changed 3 years ago by Joonas Lehtinen

Good point, but is there a use-case? Different units make sense for size, but are they really useful for flexible size limits? I am not that sure about it.

On the other hand - supporting different units could complicate the API quite a bit.

comment:3 in reply to: ↑ 2 Changed 3 years ago by Jouni Koivuviita

Replying to Joonas Lehtinen:

but is there a use-case?

The trickiest question ever. Of course someone will come up with a use case, and even if it wouldn't sound logical to us, it might be very important for them. Using ems would be the most simple example: I want to present at minimum three rows of text, but no more than 20, and otherwise have 100% height. And approximating the height using pixels will not suffice because of the varying font size.

On the other hand - supporting different units could complicate the API quite a bit.

I suppose it would be just as complex as supporting different size units currently. The API would be asymmetrical if we wouldn't support all the same units as currently, which IMO would make the API worse.

comment:4 Changed 3 years ago by Joonas Lehtinen

True enough and the em usecase is relevant.

Still - I do not see how to get the API to get even somewhat compact.


comment:5 follow-up: ↓ 6 Changed 3 years ago by Artur Signell

The way layouting is specified it has to be implemented in the layouts and not in the components. The main reason being that the parent (layout) is the one controlling the layout and has the power to decide what 100% means. The child component then must adhere to that. Otherwise we need to redefine at least how expansion works.

The question then becomes is this a feature of every component or is this a layout feature? From a code perspective it is definitely a layout feature and the API should be provided in the layout, like alignment and expand ratio. Simply adding the API to every component and noting that it only works with certain layouts does not sound very good.

If the API is added to a layout it could be:

layout.setComponentMinWidth("100px") layout.setComponentMinWidth(100,Units.PIXELS);

to be consistent with the Sizeable API

comment:6 in reply to: ↑ 5 Changed 3 years ago by Jouni Koivuviita

Replying to Artur Signell:


That would be ugly in my opinion, even though it might be consistent from the API point of view. Component alignments are of course a somewhat similar issue, yet they feel more in place than this would.

comment:7 Changed 3 years ago by Joonas Lehtinen

Artur, you mean:

  • layout.setComponentMinWidth(childComponent, "100px")
  • layout.setComponentMinWidth(childComponent, 100,Units.PIXELS);

In any case - how this is different from the case where component says that is 100% wide (layout can give any amount of space for it), undefined (an expanding layout might want to reserve at lest the amount of space used measured from the component) or 10em (handled in the same way as undefined)? Adding min-max support to component directly would just just add these values to component UIDL as minwidth, maxwidth, minheight, maxheight. Layout is then free to use these when calculating expansions.

Say we have a button B and textfied T inside horizontal layout L. L is 100% wide, B is of undefined width, T is 100% wide with no min set and 200px max width. B is at index 0 and T at index 1. T is align left and has expandRatio of 1.0. What happens when window is resized to affect how 100% width of L is calculated - lets call that LW. Button width is measured from offsetWidth - lets call that BW. When LW>=BW, button is fully visible and slot 0 given to button in L is BW wide. If LW<BW, slot width == LW and button is clipped. Then the slot 1 where T resides is LW-BW wide. Pixel width of T - lets call it TW - will be calculated as LW-BW>200?200:LW-BW.

A more complex example with multiple components with min and max widths and different expand ratios should not be any different. Expand ratios should be used to divide space left after min widths have been taken. If an expanding component gets more than its max value, the extra space should be divided between other expanding components. If there is more extra space to use by the expanding components than max values allow, the extra space should be used in proportion of expanding ratios and alignments used to position components.

As a summary - IMO the min/max values should be attributes to the components - not to layouts surrounding them. Still layouts may use there values from components to provide meaningful expand ratio calculations.

comment:8 Changed 3 years ago by Jouni Koivuviita

A little more about different units: percentage sizes as max values are very handy, and should not be disregarded.

In any case, I think these enhancements are only feasible for Vaadin 7 and not earlier. And we should probably try to rely on browsers' rendering more than currently, if that's even slightly possible (and it should be, since we're about to drop support for IE6).

comment:9 follow-up: ↓ 10 Changed 3 years ago by Joonas Lehtinen

Jouni - is there some other case for % max size than having undefined base size?

comment:10 in reply to: ↑ 9 Changed 3 years ago by Jouni Koivuviita

Replying to Joonas Lehtinen:

Jouni - is there some other case for % max size than having undefined base size?

Sure. The normal size, say width, is defined as 800px for example, and the max-width is 100%. The normal size would then in effect be the min-width, but the component would still shrink if the available space becomes too narrow.

Of course the priority of the values needs to be defined so these cases make sense. If the size value takes priority over min/max values, then percentage sizes as min/max make no sense.

comment:11 Changed 3 years ago by Joonas Lehtinen

  • Description modified (diff)
  • Summary changed from Min-Max limits for % and undefined sizes to Min-Max limits for component width/height

Makes sense. Updated the ticket accordingly.

comment:12 Changed 21 months ago by Leif Astrand

Instead of forcing each and every Layout and Component to support these features, we could also consider just creating a wrapper component that can be used in that cases where this kind of functionality is required.

comment:13 Changed 21 months ago by Jouni Koivuviita

Or as a decorator, once we get that feature inplemented.

comment:14 Changed 8 months ago by grined

Is there any news about this feature? When it can be realized?

comment:15 Changed 5 months ago by Artur Signell

  • Verified unset
Note: See TracTickets for help on using tickets.