Widgets

[charlenni]

I'm started a rework of the widgets, but need some input.

I made some assumptions about widgets. If they aren't ok, then complain about them.

1. Widgets are set by HorizontalAlignment, VerticalAlignment, Width, Height, MarginX and MarginY
2. HorizontalAlignment has the values Left, Right, Center, Stretch (use the Width of the Viewport) and Absolute
3. VerticalAlignment has the values Top, Bottom, Center, Stretch (use the Height of the Viewport) and Absolute
4. MarginX and MarginY are the distance from the border in respect to alignment
5. Width and Height are only taken into account, if the alignment isn't Stretch
6. If a Widget is touchable, then it has a TouchableArea, which could be Widget (only the area which is used to draw the widget) or Viewport (whole area of viewport)
7. Position and size is calculated before drawing the widget in the widget renderer.
8. Many widgets inherit from TextBoxWidget, which has properties for PaddingX, PaddingY, TextColor, BackgroundColor and TextSize

Any further suggestions?

[janusw]

1. Widgets are set by HorizontalAlignment, VerticalAlignment, Width, Height, MarginX and MarginY

2. HorizontalAlignment has the values Left, Right, Center, Stretch (use the Width of the Viewport) and Absolute

3. VerticalAlignment has the values Top, Bottom, Center, Stretch (use the Height of the Viewport) and Absolute

I think this satisfies many simple layout scenarios, but it may not be sufficient for more complicated cases (unless you want to fiddle with manually setting up an absolute layout). Just think of a pair of two small widgets (e.g. + and - buttons for zooming), which should be placed next to each other in one corner of the map.

One thing that I have done to overcome such limitations with my custom widgets is to introduce a WidgetGroup class that is a widget itself and contains:

• a list of widgets that it groups together,
• an orientation (horizontal or vertical) and
• a spacing between the child widgets.

The group sets up the positions of the child widgets, but they take care of drawing themselves at this position.

In this setup I also needed a GroupableWidget class, that has these properties:

• a boolean that defines whether the widget is grouped or stands by itself,
• a size (to tell the parent group how large it is) and
• a position (that will be set by the parent group)

The size is already included in your proposal (width & height), but the position is missing. You will need that for the absolute layout as well, I guess?

If there is interest in it, I could possibly contribute the implementation of the above classes (they're not very complicated). I already had that in mind, but didn't find the time to upstream it yet ...

[charlenni]

Perfect! that are good ideas, which I didn't take into account up to now. Made them until now by hand.

Do you think we need a GroupableWidget? Couldn't this handled by the GroupWidget?

Up to now, I thought, that I could handle the position by MarginX and MarginY. But now I added a PositionX and PositionY.

[janusw]

Do you think we need a GroupableWidget? Couldn't this handled by the GroupWidget?

If the Widget base class is powerful and flexible enough, one can certainly get rid of the extra GroupableWidget class.

Up to now, I thought, that I could handle the position by MarginX and MarginY.

That sounds pretty hacky. Technically one could probably reuse the margin properties (for a top-left alignment the margin would even be equal to the position), but I think separate position properties would be cleaner.

[janusw]

8. Many widgets inherit from TextBoxWidget, which has properties for PaddingX, PaddingY, TextColor, BackgroundColor and TextSize

I think another popular case would be button-like widgets that don't have a text, but show a simple icon and can be clicked to trigger a particular action. There is already a ButtonWidget - but I wonder why it inherits from TextBox, since properties like Text and TextColor have no function for it.

[charlenni]

I thought long time ago, that ButtonWidget could handle text, images or both. But there are now many different widgets and TextBoxWidget is touchable. Should be made better.

[charlenni]

Refactoring in #2370

[charlenni]

I now made a new refactoring in #2377. That separate ButtonWidget in TextButtonWidget and IconButtonWidget. Also, the widgets are now much clearer and better to extend.

@janusw I think, the GroupableWidget could be dropped, if the child widgets are set to absolute for their alignment and Width, Height, PositionX and PositionY used for their placement. With this, the child widget itself doesn't need knowledge about its status. If something changed in the parent, a new layout is calculated and above values are set. I would derive from BoxWidget and implement ITouchableWidget for the GroupWidget.

The most difficult part is the layout. What do you do, if the Widgets have different size? Do you center them? Or do you have a special flag for this?

[janusw]

I now made a new refactoring in #2377. That separate ButtonWidget in TextButtonWidget and IconButtonWidget. Also, the widgets are now much clearer and better to extend.

Sounds reasonable (without looking at the details).

@janusw I think, the GroupableWidget could be dropped, if the child widgets are set to absolute for their alignment and Width, Height, PositionX and PositionY used for their placement. With this, the child widget itself doesn't need knowledge about its status. If something changed in the parent, a new layout is calculated and above values are set. I would derive from BoxWidget and implement ITouchableWidget for the GroupWidget.

Yeah, could work. I don't oversee the implications of your refactoring yet. I have an additional flag that tells the GroupableWidget whether it is grouped or not (if grouped, the placement is done by the group, if not, the widget does it itself). If you have a mechanism to avoid re-evaluating the positioning on every redraw, maybe one can go without the additional flag. But at some level you have to decide whether the placement is determined by the widget itself or the parent group.

The most difficult part is the layout. What do you do, if the Widgets have different size? Do you center them? Or do you have a special flag for this?

In my WidgetGroup implementation I use the Orientation property of the group (horizontal or vertical) plus the HorizontalAlignment or VerticalAlignment properties to determine the alignment of the child widgets relative to the parent group.

Does it help if I open a PR with my implementation based on the current Widget API, or should I rather wait until you are done with the refactoring?

[charlenni]

Yeah, could work. I don't oversee the implications of your refactoring yet. I have an additional flag that tells the GroupableWidget whether it is grouped or not (if grouped, the placement is done by the group, if not, the widget does it itself). If you have a mechanism to avoid re-evaluating the positioning on every redraw, maybe one can go without the additional flag. But at some level you have to decide whether the placement is determined by the widget itself or the parent group.

If you set the VerticalAlignment and HorizontalAlignment in the new Widgets to Absolute, then the renderer use only the values provided in PositionX, PositionY, Width and Height. There are no additional calculations. But if you want, that the layout respects the settings of the groupable widgets, you couldn't overwrite the alignments. Perhaps a function that replaces the calculation of the envelope?

In my WidgetGroup implementation I use the Orientation property of the group (horizontal or vertical) plus the HorizontalAlignment or VerticalAlignment properties to determine the alignment of the child widgets relative to the parent group.

Makes totally sense. Perfect.

Does it help if I open a PR with my implementation based on the current Widget API, or should I rather wait until you are done with the refactoring?

I'm not sure, if my PR is accepted. It is a larger one and I'm not sure, if someone takes the time to look into it. And if it is more than, lets say, 2 weeks, it makes no sense to keep it open. Too many things will happen in this time, so that it is too problematic to integrate it. I looked yesterday into my CalloutStyleRenderer, found two bugs and need more than two hours to understand, how it works ;-)

That said, it would be better to make your own PR. We could look into it and if I see something, that should be added in my PR, then I could do this in the next days.

[charlenni]

Do you think, that it would be better to have Margin and Padding as MRect? And should Position be a MPoint instead of PositionX and PositionY?

[charlenni]

I now change PositionX and PositionY to a MPoint Position. MarginX and MarginY changed to a MRect Marging with left, top, right and bottom. The same with PaddingX and PaddingY which also move to a MRect Padding.

[charlenni]

@janusw I saw today, that we have also a Size for Width and Height. Should we use this too?